>>I think the development of certain message protocol is inevitable as
>>input tech. advances. Now we have mouse, pen (SCRIBBLE stuff), someday
>>we'll have some VR gear... The question is whether we should have a
>>logical framework to facilitate the development rather than let it happen
>>in an ad hoc and eventually chaotic way.
>
>The question at stake is also whether this "logical framework" should
>be built on top of HTTP, on top of something else, or shouldn't be
>built at all - i.e. something already exists.
If there already exists such a UIMS protocol that can be easily extended as
needed then by all means use it, if legal issue is not a concern. I don't
like to re-invent wheels either. We just need something to agree upon -- a
standard.
>A UIMS typically provides this level of service: rubberbanding,
>selection of a item in a menu, choice of a value in a scale. The
>implementation of the dialog (whether or not the valuator is a Scale
>widget or a SpinBox widget) and therefore the visual feedback, as you
>said, is typically done on the "display side" while the logic of the
>application is done where the app is run, on the "other" side.
>
>This model happens to match the Web browser/httpd architecture, but
>this is a coincidence more than anything else :-)
>
>>I submit that certain UI message protocol for www is useful and necessary
>>and that we should pay attention to design a proper message
>>hierarchy.
>
>I got your point about X events being of one kind and WWW events of
>another, but I'm still concern that we try to re-invent the UIMS wheel
>here.
>
>To some, HTML Forms over HTTP POST (or ISMAP for that matters) might
>be considered as a rudimentary UIMS, but we have to remember that
My original intention was to find out if there is any logical naming
convention for variables defined in HTML Forms by different input methods.
e.g., what variables are defined by certain input device actions? what is
the format of the value of a certain variable, etc. The convention should
be extensible and able to prevent name space pollution in the future. You
might want to call the variable naming convention a UIMS protocol, if you
insist.
>these WWW protocols were not designed to make it easy or reliable for
>the server to maintain any state about a specific conversation, or to
>exert any real control over the conversation.
>
>For instance, a WWW viewer expects a reply from the server following a
>form submission but as far as I know, it has no guarantee of a reply,
I thought it was easy to hack the httpd to include a defaut reply for
any form submissions if a form processor exits without echo a response.
Is it not?
>and it won't be informed if there is no reply (or that forms are
>presented multiple times or out of order, etc). There is very little
>dialog control available to the information provider.
>
>I'm not flaming the Web here, all this just stems from the original
>design goals of HTTP, its statelessness in particular, and we have to
>be careful when shifting our goals.
I think http is just a simple transport protocol for hypertext documents as
the name implies. In most cases (simple html documents) the problems
(concurrent/multiple form submission etc.) you just raised are irrelavent.
If there is need to deal with it, service provider can always implement his
own message queue and/or locks stuff in cgi scripts. If the demand is
strong, server vendors and or third parties might provide certain
library/packages for cgi script writers to deal with the special occasions.
I don't think sacrificing the simplicity and hence the low-overhead of the
http protocol for _occasional_ needs is worth the trouble.
>One day, I'll have to mention all the eggs I put in libXm over the
>years... No I'm kidding, we just stuffed the demos, never the widget
>set (besides bugs :-)
Post them/tell _me_! Puhleeez! :)
ACA, TIA,
__Luke
--
Luke Y. Lu ~{B@TFI=~}
mailto://ylu@mail.utexas.edu/
http://www.utexas.edu/~lyl/