[Standards-JIG] NEW: JEP-0142 (Workgroups)

Matt Tucker matt at jivesoftware.com
Mon Sep 13 05:26:23 UTC 2004


Trejkaz, 

> My only comments so far are on examples 6-9, "Join With Form":
> 
> I would be inclined to make this an explicit "get, then set" 
> procedure, like jabber:iq:request.  In reality, I'm sure that 
> the majority of these systems will need to gather at least 
> some data, and the edge case where no data is required could 
> be satisfied by sending back no form:

I can actually think of a fair number of use-cases where one might want
to not require a form. However, I don't think your idea is even mutually
exclusive with the current version of the JEP. There is no reason that a
user couldn't start the exchange with a "get" to look for form data
instead of trying to join right away. However, one thing that could be
clarified is what happens when the user does a "get" but no form is
required. Does that make sense, or am I missing something? 

> At this point, the server could also pass back 
> <queue-notifications/> such that the user's client knows in 
> advance whether it is supported.  The client can then leave 
> it out of their "set" query, if it isn't supported.

This seems like reasonable behavior on a "get" request.
 
> I'm also curious to know why the metadata is considered to be 
> different to a form, if the form is going to be gathering 
> metadata as well.  For a web-based system, the app is going 
> to be filling out the form for the user, and it might as well 
> include the metadata in the form.  For a Jabber client-based 
> system, it wouldn't seem to make sense to pass the same sort 
> of metadata to the server.

I think you're right. I believe the metadata wording is from an early
copy of the JEP before we had added data forms. I'll clean-up it up --
all standard meta-data should be handled through forms. It's always
possible that there could be implementation-specific meta-data, but
that's beyond the scope of the JEP. For example, in our implementation,
a user can pass in the agent they prefer to chat with -- if the server
is able to route to that agent, it will.

> All in all though, I think this looks pretty good for a first 
> release.  It covers much more ground than I was able to cover 
> in the system I wrote. :-)

Thanks for the feedback!

-Matt



More information about the Standards mailing list