Some more comments.
>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.
>
The protocols supported by a printer are merely capabilities that
the user's host may choose from for optimal printing. It is
effecient if the user's host can send one SrvRqst to discover
printers with the protocol set it supports. This suggests the use
of separate DA entries (i.e. one per protocol) or an effecient use
of attributes (i.e. the suggested 'concrete-protocols' attribute).
On the other hand, the user experience is important here. A
printer supporting several protocols should appear as a single
printer to the user. This would suggest one printer entry in the
DA. Separate DA entries could, however, be assembled and presented
as one printer to the user by. An attribute should then be used to
identify the printer (e.g. the 'name' attribute).
Jini has a nice way of handling this. See below.
A problem with representing an IPP printer as the 'printer:http'
SLP service type, is that other printer protocols (not IPP) also
uses http as transport.
Using 'printer:ipp:http:' comes to mind but would break the SLPv2
spec. Instead why not use 'printer:http.ipp:' or
'printer.ipp:http'? I think the second one is better since IPP is
defining printers, not a new version of http. This suggests that
IPP is the naming authority of the service which is really the
case in this discussion.
>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.
>
Java code doesn't have to be loaded until it is called if packaged
in a smart way. A Jini Printer could therefor be implemented to
support many protocols in one 'object'. This would also utilize
the search mechanisms of Jini effeciently.
A Jini service object may implement several subservices (i.e.
typically Java interfaces) to represent the complete service of a
device. The subservices may be different protocols or it may be
e.g. printer and scanner services for an MFP device. Clients
requesting print services would search for all Jini services
implementing the Jini 'printer' interface and would find all
objects implementing that Java interface. A client looking for an
MFP device would e.g. search for objects having both the printer
and the scanner interface. This makes great use of Java's multiple
interface inheritance and reflection capabilities.
I think this capability of Jini is crucial long-term for an
effecient Service Discovery protocol. I think future SLP work
(v3?) should investigate the possibility to represent composite
services. The sematics for this is not trivial. Is a device with
the 'Printer' and 'Scanner' services automatically a 'Copier'?
>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.
>
I agree with James on this. But I suggest using the service type
form of 'printer.ipp:http', 'printer.ipp:mailto:', etc. for the
separate URI entries.
/Mikael
-------------------------------------------------------------
Mikael Pahmp Software Architect
Axis Communications
Scheelev. 16 Email: Mikael .Pahmp at axis.com
S-223 70 Lund Phone: +46 46 270 18 81
Sweden Fax: +46 46 13 61 30
Visit our WWW-site at http://www.axis.com/