WWDC2001 Session 308

Transcript

Kind: captions
Language: en
good afternoon my name is Rob Neville
and I'm the manager of the service
location engineering team and apple and
this session for those of you in the
room and the dark out there is on NSL if
you came to hear about something else
I'd like to go over some of the
highlights of NSL and I'd like to start
off with some of you in the room that as
I was looking before those sessions
started I recognized from past years and
some of you were fresh faces this
doesn't mean you haven't been here just
I didn't recognize you
NSL came out of a team that was
primarily at Apple's primarily
responsible for doing personal web
sharing about four years ago and as soon
as we delivered a server on every
desktop it we became acutely aware that
it was difficult to find tcp/ip services
on the net in the same way as we were
able to find personal file sharing
servers or or Apple share servers on the
network and as people started moving
into a more dynamic environment where
they didn't have a specific tcp/ip
address from one boot to the next it
became a more critical to be able to
somehow put out to the world
or to your intranet a way to tell people
where services on your particular CPU
were located and out of that
investigation and search came NSL
network service location in an essence
in a nutshell what NSL is is a way for
servers and services that are written as
part of the OS or by people like you to
register those services on the network
and then have client based applications
find those services those services can
be registered dynamically and much in
the same way as you know ten years ago
you were doing an MVP register on an
Apple talk network you can now do an NSL
register and get your services
registered on your network they can be
found by your client based applications
through a common interface the first
year that we did NSL we basically gave
you a series of eight
is that allowed you to register services
and we got feedback from you and the
feedback from you was give us a common
UI so that for all of our client
applications we don't have to roll our
own next year we came back and you had
your common UI and we've put that common
UI into ten
excuse me into nine and into eight
before that so it's in a classic
Macintosh operating system so that your
servers can register on the network and
client applications that you write that
can connect to your servers or other
services such as Apple Script that take
advantage of NSL can access your servers
over the network as long as you register
last year the theme was you know if you
register they will find you if you don't
they won't and as we move forward it
becomes critical for you as service
providers and as developers who provide
services that customers are going to try
and access for you to register these in
particular ways we've gotten more
feedback from you since that time that
simple URL registration while it's good
because it gives the address of the
server that you're trying to talk to may
not go far enough so as part of this
particular session we'd like to have a
maybe a broader Q&A or maybe even a you
know a brainstorming session towards the
end to try and get your feedback and
where you would like to see this
technology go in the future
NSL is shipping on on the Macintosh
operating system since 8 oh it's Kabul
via the api's there haven't been any
substantial changes in the api's and no
changes in the SDK
it's a it's callable through apple
script if you have an in-house kind of
service or application that you're
trying to write and you want to find one
of the services that's available through
a Perl script you can call it through
apple script and there are multiple
plugins where you can store and/or find
the services that you wish to locate on
the network you can find them via NBP
you can find them via an LDAP plugin you
can also find them via
selphie moron SLP as we go along on Mac
os10 we have a carbon UI library the UI
is callable through the api's as well
we also it's also available through
Apple scripts so if you write an Apple
script that's running in your nine
environment it's also runnable intent
we've also made some tweaks to the UI
the tweaks we've made to the UI have
entailed some changes in functionality
and some changes in the way that the
data is organized and displayed and
we'll get to that in a little bit in Mac
OS 10 we only have two plugins as you'll
see when we get to a UI slide you only
see one but we have two plugins in Mac
OS 10 we have an SLP plug-in and an MVP
plugin the NBP plug-in is only available
through low-level API calls a lot of the
services available in the Apple talk
stack are not available all the way to
the session layer we thought it probably
would be confusing if we made that
readily available to customers when a
lot of the services that call NSL on the
in the beginning weren't weren't able to
access those those Apple talk services
we when we were here last year we talked
about having a directory services plugin
we did extensive work on a directory
services plugin we have a directory
services plugin up and running in
various people's offices it didn't make
the cutoff date didn't make the ship
date for for Mac OS 10
we don't have an LDAP plug-in per se
the beauty of directory services
especially as it relates to NSL is if
you have your data stored in primarily a
static directory out there on the
network you can use directory services
to locate the data that you wish to
store out there that gives is
departments the capability of using
existing infrastructure writing with
existing tools such as Perl to enter
corporate assets or user assets in a
directory of their choosing
we thought LDAP was one that was
utilized a lot which is why we did it on
on eight nine but they could put it in a
directory of their choosing and then
access that data through a common UI
through NSL because we make a directory
services directory services calls if
someone comes along such as people here
in this audience and there was a
presentation yesterday and directory
services someone comes along and writes
a new directory services plug-in let's
say for ActiveX though I don't know then
you can also access the same services
find URLs inside of an ActiveX directory
that you can inside of an SLP
infrastructure or inside an LDAP
directory and that's where the beauty of
directory services comes in and we still
intend and as I said we'd had it working
in the lab but it did not make the ship
date we didn't we're not doing a
demonstration today because NSL is
shipping with the OS it's shipped the UI
has been shipping since Mac OS 8 in Mac
OS 9 you had Apple script capability and
functionality there so you had access to
to the standard UI either via Apple
script earth or through making API calls
and in 10 it's there when you call
connect to connect to is a finder call
which makes a call ban into our UI
library and it searches for only things
that the in this particular release that
the finder knows what to do with in this
particular case the only plug-in that's
getting executed in Mac OS 10 as it
currently exists is the SLP plug-in that
SLP plug-in is put in to been put into a
sub container currently called local
network when you select a local network
what you see then is a list of sub
scopes of that SLP network and services
in the default scope
there are some things that are that are
different in Macko in the Mac os10
environment versus any programming that
you might be doing in Mac OS 9 threading
is different the threading mechanisms
that we used in Mac OS 10 we did not
have to port over to Mac OS 9 we did not
have to port over to Mac OS 10 you don't
have to yield to any thread
we've also broken the plugins and the
managers and the UI library into their
own frameworks in such a way that should
going forward people want to make calls
to the underlying managers to get the
raw data as it comes in over the wire
after requests those can be done is at a
lower level as we can make it these are
not just high level api's that can be
called these are part of the core
foundation libraries corporate so the
NSL UI library exists in the carbon
framework and the low-level manager
libraries exist in the core services
framework so if you're writing something
that's going to be writing to core
services you can take advantage of
making NSL api calls getting back the
data that you wish displaying that in
what form whatever format you choose if
you wish to take advantage of the common
UI that we've rolled and continue to
roll in to test and to fix bugs in then
you wouldn't want to make calls to the
higher-level UI library which is
currently in carbon the other thing that
has changed in the NSL in a Mac os10
environment is the information is no
longer available per NSL neighborhood in
addition the protocol list is handled a
little bit differently and let me let me
try and explain this a little bit and if
you called NSL and mac os9
and you've got your
quote default zone or your default
subnet or your default scope we had an
algorithm which went and checked and see
what your domain name was and that we
put what we put your default scope in
and if we've got information back from
multiple plugins we group those together
in a particular grouping in the UI so
for example if my domain was Earthling
dotnet at home and i had multiple of
servers at my home office they'd all
show up in EarthLink net in a small
corporate environment where i may have
some services that existed on a DNS
server or in an LDAP directory and I got
back common data both from that and from
SLP we did the union of the data
returned from those and put it in a
single what appeared to be a single
scope or a single neighborhood that's no
longer done basically each individual
setting as you see back to this local
neighborhood this local network this
local network will just currently will
just return us LP data our customers
don't know what SLP is and probably
don't care your customers don't care
what SLP is when Apple talk when and if
Apple Talk is enabled in this particular
environment what you would see would be
an Apple Talk container which one you
clicked on would give you all the Apple
talk zones in your network and then you
would have a local network container
which would give you all the SLP zones
in your neighborhood and you would also
see those servers that are be accessible
via directory services so each of those
are in their same their same environment
the other thing which we talked briefly
it was mentioned briefly in the Mac OS
10 server gathering yesterday was in Mac
OS 10 server were we're shipping an SLP
server well in actuality we're shipping
an SLP server in Mac OS 10
it's configurable through a common UI
that common UI has managed via remote
administration but that server is in
essence the same server that exists and
is available in every version of Mac OS
10 and it's an SLP daemon that we have
as I was mentioning it's a fully
configurable through the Mac OS 10
server and what does this give you well
this gives you the capability of
subdividing your SLP network into
logical scopes or neighborhoods their
scopes and slpeeble it allows you to
have more than one grouping of logical
devices or logical services on the
network currently everything goes by
default into a scope known as default
however they don't have to there's
always a default neighborhood which is
available and that would be what people
might see is their local environment but
there is also the ability to create
scopes on an SLP server and you could
have more than one SLP server on a
network you don't have to have the same
number of scopes in each and on each
server you don't have to have the same
names of the same scopes on each server
if you do and I register in a local
server next-door to me you're down the
hall and there's a scope for say
engineering in another building that
data will get propagated across the
network so that the person who's in an
engineering scope in building one and
myself in building two will see the same
data in that particular scope so your
network will no longer appear flat
however SLP is not a hierarchical
networking architecture it is in essence
like Apple Talk what will allow you to
do is segment your network but what
we've seen at Apple and as we rolled
this technology out internally is there
are some services in Mac OS 10 and Mac
OS 9 which register with NSL and when
you call the finder and you look for
those services primarily file services
you will see thousands of them
that is very distressing we attempt to
solve this problem with an SLP server
much in the same way as if there was no
255 node limit for appletalk if you
could have this infinitely large
appletalk zone you know what would the
confusion be in that particular case so
with NS l 10 server were shipping an SLP
scope utility basically we're hoping at
some particular point though we don't
know how this is going to be to us with
SLP this is a natural access extension
of your system preferences and much in
the same way as you designate what your
default appletalk zone is you'll get an
opportunity to designate what should
what default scope you're going to be
putting your service into and it's also
you can choose which scope you want via
an apple script in Mac OS 10 excuse me
in Mac OS 9 there is an apple scripts a
strip chips with the printer utility
that allows you to choose which scope
you wish to be in and that becomes even
more useful now that we're shipping an
SLP server on Mac OS 10 so now we get to
the point where we're gonna want some of
your feedback and before I ask for your
feedback here I'd like to tell you some
of the things which we're thinking about
doing all right and then I'd like to ask
you whether or not we're going in the
right direction whether or not there are
more things that you'd like to see are
so there's some things we haven't
thought of basically let us know what
you what you think we had some feedback
last year just one but I wanted to bring
it up again because we don't have it we
have a carbon UI library and we have
been thinking internally about providing
a cocoa UI library we also are moving to
use core foundation types in the in the
SDKs and then the api's that would mean
some changes to your code
we also are
going to attempt I've been thinking
about making the UI much more
customizable currently we have a few
options you can display the text edit
box or not you can display the list of
services that you want people to switch
to or not
a pop up fairly minor kinds of things
and we're looking at providing more
options in the NSL UI library we also
have been exploring the possibility of
providing and would like to get your
feedback on this providing a full SLP
library with support for all SLP
attributes as part of the core OS and
we're also working for and attempting to
have more seamless integration with NSL
and as part of the finder experience one
of the other things that we've been
looking at is a concept of meta URLs as
I as I mentioned at the beginning we've
been around for about four years and
when we started doing this development
we were looking at solving a particular
problem
well since NSL now has been out for
three years we're starting to get some
feedback as to how people are actually
using the product one of the people that
is a primary customer of our product
currently is the is the finder under mac
OS and the finder knows about files it
knows about file systems well excuse me
it doesn't know about file systems it
knows how to move files around in a file
system but it only knows what to do with
files it doesn't know what to do with
web pages from a display standpoint it
doesn't know what to do with printers so
what we were thinking about doing is
having a prefix to the URL which would
basically say what the type of service
was how does this impact you well if you
agree and we we move along
the adoption of this particular approach
it would mean probably registering more
than one URL type when registering the
URL I'm in a WebDAV server and
registering it being an X file so that a
service that knows different services
that know how to handle different types
could say give me all the types of file
then if you have a plug-in architecture
of some sort
you don't necessarily a runtime know
which file systems are loaded or which
file you are else remote file URLs you
know how to handle but you say give me
the types file on the network I will I
will then pass off the URL to whatever
my mounting mechanism is which may be
different for NFS which may be different
for AFP which is different definitely
different from web dev and then that's
that service will get mounted in the
current OS this is basically the way it
works except there's no freeform
extensibility basically the filesystem
knows how to handle filesystem right
out-of-the-box knows how to handle an
and mount AFP volumes and efest volumes
and web dev volumes you can at the
connect to prompt type in URLs for AFP
NFS or HTTP and that HTTP will get you
to a web dev if that web dev if there's
a web dev server running at that address
and but it only cares about mounting
file systems it passes that that URL
data off to URL mount URL mount then
goes and mounts it in the file system
once it's mounted in the file system the
finder deals with it as it does any
other any other mounted volume you may
also have a need or a want to connect to
a particular different types of web
services or services of your own design
so that your you may design a
a plug-in architecture into your
particular system at runtime you don't
don't necessarily know what plugins are
running register dos those systems get
registered at runtime to know how to
handle particular URLs the servers that
you're keeping your data on will
register what services are running on
their machine the UI that you use to
find those services would be dynamic be
able to find those and then you would be
able to handle them and branch those off
appropriately in addition we're looking
at extending the URLs to handle
attribute lists the primary impetus for
this has come from printer folks they
want to be able to browse for printers
that handle color printing two-sided on
Wednesdays and there's no real way to
encode that in a URL that that we're
used to dealing with right now
with the advent of our SLP server
network administrators and/or people who
are running print shops with printers of
different types
if the printers don't have this
registration for themselves built into
their firmware can register these things
with our SLP server and or put it in an
LDAP directory or net info directory or
an ActiveX directory or whatever because
of directory services and then there
people using the utility to access that
printer can find it on the network can
switch between one or another depending
upon what the attributes are they can
put up depending on what attributes are
attributed with the registered server or
the registered printer out there and the
network can change the dialog box
appropriately so what we're looking at
and what we've been discussing is is
having a group of meta URLs so it's
Wednesday afternoon what I understand is
that at six o'clock they're gonna start
serving pizza and we're at a point with
NSL where we've delivered a technology
we've talked to developers we've talked
to you all out there some of you who
developing and are using this technology
in a sort of new way new in that you've
got a technology that it really hasn't
rolled out into a production environment
as as of yet but are you're exploring
the possibilities well we don't want to
make changes to NSL that negate the work
that you've been doing if there's
something in NSL and in finding the
services on the network which is what
we're after would that work service
location that you need and/or want we're
listening
you