[standards-jig] Future Client Expectations

Mike Lin mikelin at MIT.EDU
Wed Apr 3 15:11:48 UTC 2002


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
messaging.

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.

-Mike

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.
> 
> --temas
> 
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 





More information about the Standards mailing list