[standards-jig] disco, x:data, etc...

Matthew A. Miller linuxwolf at outer-planes.no-ip.COM
Thu Feb 20 17:08:14 UTC 2003


Apologies for the multiple copies.  My MUA is not cooperating today...


-  LW

On Thu, 2003-02-20 at 09:04, Matthew A. Miller wrote:
> 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.
> 
> 
> -  LW
> 
> 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?
> > 
> > Because:
> > 
> > 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
> > http://mailman.jabber.org/listinfo/standards-jig
-- 

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 mailing list