[standards-jig] disco, x:data, etc...
Matthew A. Miller
linuxwolf at outer-planes.no-ip.COM
Thu Feb 20 17:04:53 UTC 2003
I request that you again read JEP-0050 before discounting it. Your
first argument against x-commands is not valid, and the second is vague.
To address the first argument, no where in the draft does it say that
*only* x:data elements can be used for the payload.
Quoting Section 4.3 ("<command/> Element"):
Each <command/> contains attributes for a node, a "session id", a
state type, and a status type. A command may contain zero or more
<note/> elements, and may contain additional elements for an
execution's data. Elements in the "jabber:x:data" and "jabber:x:oob"
namespaces are the typical payload.
Now for the second argument. What exactly in x-commands is "hard
processing from both client and server side"? So far, you have brought
forth concrete issues with "sessionid" and "status":
1) "sessionid" is currently required. It's for tracking command
execution, in much the same way that web application servers (e.g.
Jakarta-Tomcat, WebLogic) use a similar variable. Allow me go further
into this for the requester (aka "client-side"; 1.A) and the responder
(aka "server-side"; 1.B).
1.A) All the requester needs to do is pass along the same value (until
receiving a status='canceled' or status='completed'). It is not even
required for the requester to maintain this between transactions
(iq-set/iq-result pairs) of the same command execution.
1.B) The responder is required to provide one that is unique between the
same requester and responder. There are literally thousands of
algorithms that can be used to do this. Also, although this can allow
same requester to execute the same command several times simultaneously,
the responder is not required to support this (see Section 3.3).
2) "status" is an indicator as to what state the execution is in. This
immediately lets the requester know if a response is expected/permitted
(status='executing') or if the execution is over (status='completed' or
status='canceled'). And if the responder doesn't know what state an
execution is in, it most-likely has much bigger problems.
On Thu, 2003-02-20 at 06:58, Alexey Shchepin wrote:
> Hello, Matthew!
> On 19 Feb 2003 11:53:39 -0800, you said:
> MAM> First, the admin problems that Alexey is trying to solve are
> MAM> exactly what x-commands is designed for. Why not just use
> MAM> x-commands?
> 1) x-commands not indended to include other namespaces than x:data
> 2) x-commands adds "node" attribute, but also adds useless in this
> case additional element, namespace and more hard processing from both
> client and server side.
> MAM> Second, FORM_TYPE (currently) does not fully address Alexey's
> MAM> issue,
> IMHO it address jep-0004 issue. x:data is used both as human-readable
> (i mean human can use it when it showed in client) and as
> machine-readable (e.g. in negotiation protocol). But:
> 1) From machine side it contain useless elements (like instruction,
> title, and field with type fixed) -- this is not bad, but shows that
> it not only for machine.
> 2) From client side it looks like a non-extensible and non-flexible
> protocol, because:
> a) Field types set are fixed. And fixed with some strange
> types like "jid-single" and "jid-multi". Why so many
> attention to JID? Of course in some situation we need to
> enter JID, or list of JIDs, but sometimes we need to enter
> date, time, etc... IMHO better replacement for this looks
> like this: <field type="text-single" subtype="jid" .../> and
> for date <field type="text-single" subtype="date" .../>. Or
> even better to make list of options for each field type. And
> IMHO JEP-0068 looks better if it will have no fixed var names
> for each FORM_TYPE, but will have additional attribute that
> points to it meaning in given FORM_TYPE. This helps if this
> form can have not fixed number of elements (for which we must
> use different var names).
> b) If we want to display to human list of fields, then we need
> to know that for human hard to search requred field from list
> of 30 values, it should contain no more then 10 elements to be
> easily understandable. In interfaces this usually solved by
> grouping of fields. So if we have <instruction/> and <title/>
> that intended only for displaying for human, why not to have
> <section/>, so clients can handle it e.g. by displaying
> sections in different tabs, by making something like table of
> contents in beginning of list, or by ignoring it.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Matt "linuxwolf" Miller
JID: linuxwolf at outer-planes.net
E-MAIL: linuxwolf at outer-planes.net
- Got "JABBER"? (http://www.jabber.org/)
More information about the Standards