[Foundation] Growing Concerns for Client Developers

Adam Theo adamtheo at theoretic.com
Sun Oct 7 20:52:18 CDT 2001


temas <temas at box5.net> 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.

/me ponders... Yes, I agree. I realize that this is the model that
Jabber was founded on, and I believe it should continue. However, being
one who is very interested in helping to take Jabber into p2p (as in,
clients talking and processing directly with each other, not through the
servers), I have to say I think instad of keeping our eyes focused on
the client/server model, now is a great opportunity to start revising
the jabber protocol and platform to easily work in both client/server
and peer/peer models. two platforms that are easily interchangable and
really just the same thing, just implimented in different ways. I don't
disagree that focusing on the client/server aspect should be done right
now. After all, it is what Jabber developers are most familiar with. But
what I am saying is let's keep ourselves from cutting out the
possability of p2p in the future by focusing on only the client/server
model now. Comments?

temas <temas at box5.net> wrote:
> 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.

Iain Shigeoka <iainshigeoka at yahoo.com> wrote:
> Would this be best served be creating a JEP I'm not sure.  Perhaps a well 
> advertised whitepaper with links to it from everyplace a developer is 
> likely to go for info (docs, standards, jigs, etc) would serve better.  I 
> would tentatively guess that many people will only look at the JEP's as a 
> last resort (the term RTFM being evidence of that trend).  :)

I agree with Mr Shigeoka here. A whitepaper would not only be more
'reader and press friendly', but also more appropriate, since it seems
JEPs are mostly raw techie and implimentation-oriented info, not
intended for purely educational reading.

Iain Shigeoka <iainshigeoka at yahoo.com> wrote:
> I agree.  At the very least, if we have Jabber "environments" we must 
> provide for one that is limited enough to allow quick/small implementations 
> of clients.  This should support simple implementations as plugins for 
> other applications (similar to the ease of adding rudimentary email 
> capability to a program) as well as resource constrained devices such as 
> mobile phones, 2way pagers, etc.

Haha, by chance are you referring to my talk a little while ago about my
idea of "Jabber Environments"? If so, thank you, I'm glad someone was
listening. If not, then we could very well be thinking along the same
lines. Perhaps we should talk about this more, in public or private?

But yes, I agree. If "Jabber Environments" come to be, that should allow
for the flexability of simply/complex client models without burdoning
down the Foundation or the protocol itself.

Peter Saint-Andre <stpeter at jabber.org> wrote:
> 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).

Yes, I agree. This is where my above-mentioned "Jabber Environments"
idea comes in. With this idea, Jabber itself would encompass alot of
"standards", all approved and governed by the Foundation. The
Foundation's job would be to keep these standards to a minimum while
allowing for complete flexability (cut out the crappy standard proposals
like it does now, no change). But instead of "packaging" and "labeling"
these standards itself, it would leave that up to "Jabber Environments"
which would pick and choose parts from the "greater cloud" of the Jabber
protocol and package it all into easy to understand definitions and
boundaries, possibly also with development tools and information.

One such example is my "Crown Jabber Environment" I've been slowly
working on. Crown would be a peer/peer (as opposed to the current
client/server) conversation (as opposed to RPC, web services, push
presentation, etc.) platform. Focusing on conversation, it would cover
the current IM-ness of Jabber, but also cover telephony, video
conferencing, email, and some collaboration aspects. Crown would have
it's own definitions and boundaries of what is and isn't Crown. Other
Environments could exist that cover the traditional client/server model,
web services, push presentation, etc.

So by using the Jabber Environments idea, there could exist such an
Environment that packages the traditional, very simple, client/server
instant messaging aspect, called possibly the "Simple IM" Jabber
Environemnt. Make sense?

I'm a ardent supporter of this "Environment" idea simply because it
would provide a perfect balance of flexability and standardization to
Jabber and the Foundation.

"Harold E. Gottschalk Jr." <heg at sirlabs.com>
> 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.

Agreed. One thing that all Environments support is this single
jabber:client namespace, to make sure a Crown client is not talking
with, and confusing, an IMissary or Simple IM client with features they
do not understand (Crown could instant message with a Simple IM client,
but could not do telephony or such, obviously).

I would like input on this Jabber Environments idea, especially as a
solution to the upcoming confusion between clients and end users.
-- 
   /\    --- Adam Theo ---
  //\\   Theoretic Solutions (www.Theoretic.com)
 /____\     Software, Politics, and Advocacy
/--||--\ email: theo at theoretic.com   AIM: Adam Theo 2000
   ||    jabber: adamtheo at jabber.org   ICQ: 3617306
   ||  "Did you ever get the feeling the world was a tuxedo,
   ||     and you were a pair of brown shoes?"



More information about the Members mailing list