[Foundation] Growing Concerns for Client Developers
Harold E. Gottschalk Jr.
heg at sirlabs.com
Thu Oct 4 12:52:41 CDT 2001
Some very good points, all very valid.
1) Core Protocol KISS
2) Extensions are differentiators between on Jabber offering versus another.
Do not limit innovation, by regulating extensions. When multiple
implementations of an extension exist, then the parties that have developed
those extension may choose to collaborate to provide a common protocol.
This protocol extension can then be officially adopted by the foundation or
3) Suggestion that a standard way for a client to be asked what services it
supports may be something that should be added to the current protocol. I
am sure the basics for accomplishing this are there just needs
formalization. Then it is up to the client to interact in a friendly manner
with another client.
> -----Original Message-----
> From: members-admin at jabber.org [mailto:members-admin at jabber.org]On
> Behalf Of Peter Saint-Andre
> Sent: Thursday, October 04, 2001 10:33 AM
> To: members at jabber.org
> Subject: Re: [Foundation] Growing Concerns for Client Developers
> Thanks for bringing this up. I don't think anyone wants Jabber clients to
> become as bloated as browsers. On the other hand we're trying to build in
> more advanced functionality such as file transfers, browsing, forms,
> conferencing, whiteboarding, and so on. I'm a firm believer in keeping
> things simple, however there are uses for Jabber way beyond IM and perhaps
> it's best to differentiate between core messaging functionality and the
> more advanced stuff. At some point it will be hard to know just by looking
> at an application whether it really is a Jabber "client" (it could be as
> small as a news ticker with no chat capabilities or as large as an
> integrated development or content management application a la Groove).
> I feel that in order to perform simple functions, simple XML (the current
> protocol) should be all that is required. The question is how simple do we
> want to keep the protocol in order to complete more advanced use cases?
> On 4 Oct 2001, temas wrote:
> > One of the original goals of Jabber was to keep the clients simple, so
> > that we could have more clients on more platforms. Some recent trends
> > in the amount of information and requirements that are being pushed on
> > to the client are beginning to scare me. Some of the ideas that are
> > starting to foster in the JIGs would require clients to implement heavy
> > protocol pieces and engines such as XPath and XSLT. While both of these
> > technologies are great, I feel they are better left to the server side
> > of things. Clients should only need to understand simple XML parsing,
> > namespaces (although that needs to be fixed all over the place), and the
> > XMLStreams protocol. We currently have no guidelines or suggestions for
> > how a JIG should form it's technology, especially with relation to
> > clients. Maybe we need an informational JEP outlining the principles of
> > Jabber XML and client simplicity with regards to protocol handling? I
> > think this could greatly benefit newcomers in general and our protocol
> > designers.
> > --temas
> > P.S. - Yes I am indirectly implying I would work on this =)
> Members mailing list
> Members at jabber.org
More information about the Members