IPP> PRO,MOD> User model for clients

IPP> PRO,MOD> User model for clients

Robert Herriot rherriot at Eng.Sun.COM
Thu Jan 30 21:10:01 EST 1997


Roger,


With your example below, I would expect that the html response could
be a collection of attribute values to display -- the supported values
and each default.  The user can then make changes and when the user
clicks the submit button, the client returns a list of values, one for each
field, i.e. attribute.


In the general sense, HTML forms are just another language for describing
a GUI. Any program, including a Web Browser can display an HTML form.


If the program displaying the HTML is something other than a Web Browser,
then users will probably view it as a dialog box and not realize that
HTML is underneath. HTML needs a few more features before it can describe
all the GUI features we might want, but I expect that will happen in time.


So, I think that HTML is quite adequate to handle your job submission
scenario below.


Bob Herriot




> 
> Don Wright wrote:
> 
> Here you are clearly wrong.  Lexmark's MarkVision for
> the WEB is able to provide printer and printer Queue status
> on unmodified, unassisted browsers today.  If our scenarios
> and models do not support this mode of operation then a
> grave design error has been made.
> 
> RKD> Don, I'm not sure what you mean here. Clearly one can
> RKD> continue to use existing browsers as you have in
> RKD> MarkVision for the web. However, you can't, in my mind,
> RKD> mix the two.  For example, the following seems to be
> RKD> difficult, if not impossible:
> 
> Client                                    Printer
> 
>  --------------------------------------------->
>    get printer capabilities (IPP request)
> 
>  <--------------------------------------------
>    capabilities (html ala MarkVision)
> 
>  --------------------------------------------->
>    print request, using capabilities (IPP)
> 
> 
> 
> 



More information about the Ipp mailing list