[standards-jig] Future Client Expectations
MikeO at theriver.com
Thu Apr 4 15:38:35 UTC 2002
I have been involved with a number of "Protocol" initiatives including SWAP,
WfMC/xml and others and while I have seen protocol bloat and attempts at
"extensions" to achieve (usually) someone's specific needs. Standardization
of these "extensions" is a good thing as it allows people that WANT to use
them to know how...but alongside the extensions should be a mechanism for
discovery and negotiation, so clients don't have to implement them, they
don't even have to respond...if the client doesn't know about an extension
then it never gets negotiated and problem solved.
The perfect example is the ability of some Jabber clients to handle files,
while others do not...you can send a file and think it went through, but if
the client on the other end doesn't do files...well you don't know do you?
The discovery and negotiation rules should be in the protocol, and then even
non standard 'extensions' can be handled by cooperating parties over the
Jabber protocol and all is well.
God Bless America!
Chief Technology Officer
Morningstar Systems Inc.
7391 S. Bullrider Ave.
Tucson, AZ 85747
"Learn as though you would never be able to master it;
hold it as though you would be in fear of losing it."
Confucious (551-479 BC); Chinese philosopher.
to chat. hotComm Link <http://ollie.im-live.com/im-live/>
If I'm not immediately available, please try later
or check my ezPeer home page at
Click to subscribe to KMPro <http://groups.yahoo.com/group/KMPro/join>
From: standards-jig-admin at jabber.org
[mailto:standards-jig-admin at jabber.org]On Behalf Of Mike Lin
Sent: Wednesday, April 03, 2002 8:12 AM
To: standards-jig at jabber.org
Subject: Re: [standards-jig] Future Client Expectations
One thing I find attractive about Jabber, and that we should consider
when designing things like jabber:iq:browse, is its built-in facilities
for division of labor via multiple resources, so that you don't
necessarily have to have one client that does everything Jabber can do.
Moreover these different pieces of your infrastructure can be
distributed across different devices.
I think if the final vision is realized it should not be uncommon for
someone to be connected with around a dozen resources at once, for
things like calendaring, whiteboarding, etc. as well as simple
I think this division of labor will make it practical to build all these
services for the desktop, because each component can be built
separately, and they only need to interact with each other to a limited
extent. But I do think generally the "simple protocol, minimal client"
model is only going to be true in certain cases (e.g. mobile devices).
By an end-to-end argument you simply can't effectively provide all the
rich communications services we would like without doing some heavy
lifting on the client side.
On Tue, 2002-04-02 at 23:58, Thomas Muldowney wrote:
> As I've stated many times I'm currently looking at the XML Encryption
> Standard, XML Digital Signature, XKMS, XForms, and a bunch of the other
> w3 XML standards that pertain to Jabber. After chatting with Ryan
> Eatmon for a while we started to ponder on a hard topic, what are the
> future expectations of our clients?
> The original design philosophy for clients was to keep them as simple as
> possible. This included what they had to handle as well as the protocol
> that they had to interact with. Recently, the computer industry has
> found it necessary to only have a few apps that handle tons of things,
> or as Ryan puts it, the Craftsman 10 in 1 wrench. No body seems to care
> about the single wrench anymore, with slightly different handles or
> slightly different spacings. Just take a look at the web browser, it
> does everything =) So I'm wondering where we're headed in the Jabber
> world. As I look at the w3 specs we see heavy namespace, schema and
> XPath usage, and really, that's just the tip of the iceberg. I'm not
> saying these are bad, they are definately interesting and have their own
> merits, but they are by no means the simple protocol and handling we
> used to love for our clients.
> So my question is, how much would people accept in our new protocol
> extensions? Can we start to incorporate XPath safely (I doubt it),
> Namespaces (no the server can't handle them well), other things
> (XPointer, XInclude, etc). Where do we draw the line? What are our
> current goals for clients? What are our future goals? I'm really
> interested in everyones opinions, and hopefully we can start to form
> some sort of doc outlining what protocols should keep in mind in
> relation to clients from this.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Standards-JIG mailing list
Standards-JIG at jabber.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mike Oliver.vcf
Size: 139 bytes
Desc: not available
More information about the Standards