Bob,
A few comments.
>Ira was assuming that an SLP DA would contain exactly one entry per printer.
>It would be arbitrarily associated with one of the printer's URI and the
>collection of attributes would contain information for all of the printer's
>URI. Ira preferred having one entry per printer because it reduces the
>amount of information to register and avoids the propagation problem where a
>DA, during times of re-registration has a mixture of new and old
>registrations for a printer. This problem arises with printers because they
>typically support many protocol stacks, and thus potentially many URI's.
>
If the printer is supporting many protocol stacks, and each URI is providing
the way to contact the printer through a different protocol stack, then
having one entry in the DA is actually less efficient for the client.
The client has to do a SrvRqst in order to get the service URL, then
a AttRqst to get the attribute, then select out the protocol it wants
to use to talk to the printer.
If, instead, each protocol stack/URI corresponds to a separate service
URL with service type registered in the DA, the client only has to do a
single SrvRqst to get the URL it wants. In this case, the client doesn't
have to do the AttrRqst and doesn't have to process the returned attribute to
select the protocol it speaks. This is more efficient.
With regard to re-registration, the SrvDereg request can be used to
deregister the old service URLs before registering the new ones. Thus, there
never needs to be a mix of old and new information in the DA.
With regard to the amount of information registered, it is true that
there will be more service advertisements if each printer URI corresponds
to a different service URL. However, I expect implementations of SLP
on system platforms will be optimized for fast lookup. We have
an implementation on Solaris that performs quite well even at
high loads, for example. I haven't seen any performance numbers
on Novell's implementation, but I believe it would handle high loads as well.
>As we talked about it, I realized that Ira's solution is closer to the way I
>understand Jini to work. Each name service entry in Jini is just a
>collection of objects without any special name associated with it. We can
>make SLP look like Jini if we view the SLP name as an object handle, and the
>SLP entry as the collection of objects referenced by this object handle.
>
Actually, I think the solution of having a separate service URL for
each protocol stack would simplify a Jini implementation as well.
What the client gets back in Jini is a service object supporting
a Java interface. So the operations on the object are common to all
ways of talking with the printer. The client application code calls the
interface operations and need not be concerned with how they are implemented.
If there is one printer service advertisement with all protocols
associated with it, then the printer object must support *all*
protocols. This doesn't seem very modular nor particularly efficient,
since the client is essentially requried to load code for protocols
that it doesn't need. If, on the other hand, each protocol
stack supported by the printer is a separate printer object, then
the client only needs to load code for one protocol. The latter design supports
thin clients better.
An alternate implementation would have the Jini lookup server return
a "factory object" which the client would then use to create a
printer object supporting the protocol it needs, with the factory
object doing the code loading for the driver. But why go through the
extra step of having the factory object when Jini provides you with
the code loading?
Incidently, work on an SLP/Jini bridge that will transparently support
forwarding of SLP registrations into Jini is in progress.
>When we examined the issue of associating each URI with security
>information, I realized that we could use the "service: URL"
>syntax for security information. A "service: URL" can have attributes that
>follow the URL path and that these attributes can be defined in the printer
>template document. It isn't clear to us if the attributes names in the
>"service: URL" should also appear as regular attributes in the template. Do
>any svrloc experts know?
If attributes appear in the URL, they should, for consistency's sake,
appear in the template as well.
>>So we think that the solution is that a printer registers a single entry and
>that one of the attributes is "printer-uri-supported", which contains a
>collection of "service: URLs", one for each way that the printer can be
>contacted. Each of those URL's must have all information needed for a client
>to be able to communicate with the printer. The name of this entry in the DA
>is arbitrary, but the first URL in the printer-uris-supported is reasonable.
>
As discussed above, I think this solution would be considerably less efficient
for the client than having a separate service: URL for each protocol supported
by the printer. The impact on the DA of the additional registrations would
be minimal.
jak