[Standards-JIG] Ad-hoc commands vs. separate protocols

Maciek Niedzielski maciekniedzielski at wp.pl
Sun Jan 2 22:30:13 UTC 2005


Recently, 'best practices' JEPs using Ad-hoc commands started to show up.
I understand that - provided we have ad-hoc implementation -
implementing such protocols is extremely fast and easy.
However... how far should we go this way?

I'm going to exaggerate, but I may imagine doing things like:
- sending a message
- registering in a transport
- doing client's configuration
- doing almost all GUI stuff
via ad-hoc commands + x-data forms

And what about good old IQ-based protocols?

For example, let's take JEP-0013 (Flexible Offline Message Retrieval).
Why not to make server send forms with a list of messages, etc?

I think that sometimes it would be good to give the client author the
right do design GUI. Or more clearly: The client author should be able
to design the GUI always when... it is possible.

As far as I can understand the idea of Ad-hoc commands, their purpose is
to serve interface for *unknown* operations.
For example: if I write a bot, I may want to provide the list of it's
command via ad-hoc, instead of forcing user to type magic words in the
chat window. I cannot write email to all client authors asking them:
"please provide a dialog box with these options for my bot!".
I cannot do this, so I use ad-hoc commands.

And if I write a JEP, then everyone knows what is going to happen and
what options should be displayed. So... every client author may provide
a nice looking GUI that suits his client in the best way.

-- 
Maciek
 xmpp:machekku at chrome.pl



More information about the Standards mailing list