Scott responded to the "Example of multiple levels of driver
using IPP and HTTP" section of my mailnote
>You suggest "issuing an HTTP Get" on the URI. This implies that the URI
>may only be an HTTP scheme URI. What about some other scheme?
>Should we force it to be an HTTP scheme URI?
I took HTTP as an example. FTP could also be a valid scheme. I selected
HTTP as an example because its transfer response is immediate. HTTP
has the capability of informing the server of the client environment built in.
I don't think we should force driver installation services to be an HTTP
scheme. I want to see how the prototypes handle it and evaluate the solutions
at that time.
Scott also question the following section in my mailnote:
PZ> Driver installer obtained from URI in IPP fashion. Issue an HTTP
PZ> Get to the URI from the printer-driver-installer attribute to get the
PZ> appropriate driver. Included in the Get will be IPP specific product
PZ> tags. The Installer will use IPP product tags in the HTTP Get request to
PZ> determine which installer to download to the client.
>This implies some sort of tags in HTML? Do we need to define the new
>tags? How is this different than the Super Installer from the section
>before? Isn't the this "IPP fashion" just the super installer?
I am implying that when IPP takes up driver installation one solution would
be to define IPP specific tag(s) to enable the retrieval the correct
variant of a
driver installer. There are other solutions. In my example I needed IPP
specific tags to convey variant selection criteria unambiguously.
The difference between this case and the superinstaller case is how the
client environment is determined. The superinstaller executes on the client
machine. This could be accomplished using Java. The superinstaller
determines the client environment locally and installs the driver in a platform
specific manner. In my HTTP Get example the client send its environment
information in the request and the installation service uses the tags to return
the correct variant.