Always something

Smack Smack Dev
1

Hi Matt,

I’‘ve been playing with the new IQ facilities and it looks good. However, the jabber people have thrown a monkey wrench into the works. One particular IQ protocol, “Last Active” (JEP-0012), returns data as an attribute of the query tag instead of as sub-elements. Seems rather pointless for them to do it that way since as far as I’‘ve seen, there aren’'t any others that do it that way.

Anyway, as a solution, perhaps the parseIQ method of the IQProvider interface could leave the parser on the opening query tag instead of advancing it to the next tag (which in the case would be the closing query tag) so the routine could get access to the attributes of the query tag.

I haven’‘t tried it yet, but I’'m assuming that my parseIQ routing will be able to back up the parser to point the the query tag again as a work-around.

Also, it would be convenient if the attributes were used to set beans by parseIQWithIntrospection…

Also, are you planning on using this same try of mechanism for handling “x” stuff embedded in message packets as well?

Thanks & take care,

John

2

John,

I could switch the parsing logic to not advance past the query tag to fix the issue. Or, maybe we should email the JEP authors to suggest they change the JEP to be more standard?

Also, it would be convenient if the attributes were

used to set beans by parseIQWithIntrospection…

Attributes of just the query tag or also attributes of sub-elements? It gets a bit tricky to come up with the correct logic I think. So, it may just be better to keep things simple and make people create IQProviders for the tricky stuff.

Also, are you planning on using this same try of

mechanism for handling “x” stuff embedded in

message packets as well?

X data obviously needs a good solution too. I’‘m thinking the right approach there might be some super-light version of DOM, though. I’'m very willing to take ideas on this though!

Thanks,

Matt

3

I could switch the parsing logic to not advance past

the query tag to fix the issue.

Actually, now that I’'m actually giving IQProvider a try, it actually does call parseIQ with the parser still sitting on the query tag. I guess that makes the docs wrong

Which is a good thing since I see there is no way to back the parser up (that I can see).

Or, maybe we should

email the JEP authors to suggest they change the JEP

to be more standard?

It looks like a pretty flaky “de facto” standard anyway. You could email them, you guys are a jabber sponsor now!

Attributes of just the query tag or also attributes

of sub-elements? It gets a bit tricky to come up with

the correct logic I think. So, it may just be better

to keep things simple and make people create

IQProviders for the tricky stuff.

Well, I was just thinking attributes of the query tag but I think you’'re right. An IQProvider should be written for the tricky stuff and the current behavior seems to be fine.

X data obviously needs a good solution too. I’'m

thinking the right approach there might be some

super-light version of DOM, though. I’'m very willing

to take ideas on this though!

For X data, why not just use the same type of method as for the IQ plugins and just add an array (or map or whatever) that holds the various objects created during the parsing process. i.e. messages packet could have an array which could hold a “jabber: x :delay” handler object (XProvider?) as well as an embedded roster item, etc…it would be up to the application to actually check the array and do something with the extra items. This could actually be a generic feature of “packet” so when they add the ability to embed stuff in any packet type you’'d be covered without having to change Smack.

Thanks,

John

Message was edited by: insurgent

4

Actually, now that I’'m actually giving IQProvider a

try, it actually does call parseIQ with the parser

still sitting on the query tag. I guess that makes

the docs wrong

Cool, I’'ll fix the docs. The end of the parseIQ method call should also end with it positioned on the closing query tag instead of after it as the docs said.

Or, maybe we should

email the JEP authors to suggest they change the JEP

to be more standard?

It looks like a pretty flaky “de facto” standard

anyway. You could email them, you guys are a jabber

sponsor now!

Ok, I’'ll send them a message.

For X data, why not just use the same type of method

as for the IQ plugins and just add an array (or map

or whatever) that holds the various objects created

during the parsing process. i.e. messages packet

could have an array which could hold a "jabber: x

:delay" handler object (XProvider?) as well as an

embedded roster item, etc…it would be up to the

application to actually check the array and do

something with the extra items.

This is a nice idea. Let me think about it a bit more, but it seems like it could work. I suppose there could be a “generic” mode too, where it would essentially return a Map of all the name values/values that it found inside the x element (this wouldn’'t handle attributes).

Thanks,

Matt

5

I’'d vote for a method that handled attributes. I just browsed over the XMPP IM spec and it seems to use attributes all over the place, even on BODY/SUBJECT elements of messages (to specify language/encoding) where the Jabber spec specifically forbids using attributes on the body element.

Take care,

John

6

FYI…from the Jabber folks who authored JEP-0012.

“There are really no hard fast rules as to what a protocol snippet should look like. The only sanity check comes down to the council.”

Original Message-----

From: Thomas Muldowney temas@box5.net

Sent: Monday, May 05, 2003 11:35 AM

To: info@eforceone.com

Cc: jeremie@jabber.org; temas@jabber.org; stpeter@jabber.org

Subject: Re: JEP-0012 Feedback

Because there’‘s no reason for it not to be there? It’'s actually more

preferred, now, to use more exact roots and even attributes on the

roots. Many of the other protocols that use children elements under the

do so because there isn’'t any actual attributes to carry along

with the . There are really no hard fast rules as to what a

protocol snippet should look like. The only sanity check comes down to

the council.

–temas

JEP-0012 seems to be inconsistent with the element used elsewhere in the Jabber protocol.

Everywhere else that I can see the element is used, the information

is contained in sub elements of the tag. Why for the last activity

did you decide to make it an attribute of the query element?

This is not consistent with usage in:

Authentication JEP-0078

Registration JEP-0077

Data Gathering JEP-004

XML RPC JEP-009

Subscription

Roster Management

Software Version

Entity Time

Agent Information

7

Yep, I actually had a discussion about this issue on the xmppwg mailing list over the past few days. I’‘m changing the providers file so that you specify an element name and a namespace. This will mean that is no longer required. I’'m also about halfway done on making packet extension parsing pluggable (arbitrary sub-elements of a packet).

Regards,

Matt

8

I’‘m locking this topic now to avoid future confusion because I’‘m totally changing the implementation of IQProvider and creating a new class called ProviderManager which will handle IQ’'s as well as packet extensions. All new discussions about this functionality should go in new threads.

Thanks!

-Matt