[standards-jig] Future Client Expectations

Lars.Nilsson4 at sas.no Lars.Nilsson4 at sas.no
Thu Apr 4 07:55:45 UTC 2002

I agree with Muldowney; there is a demand for the Craftsman 10 in 1 wrench. 

Our company hosts applications for a pretty large company (some 30k). The
have a major cost problem with all the applications (close to 400!) floating
around in their business. The cost for maintaining license, upgrades, user
support etc is phenomenal! 

We believe it is possible to cluster quite a few of them into a IM services!
This will reduce cost and maintenance for our customer. Therefore i agree
with Muldowney.

BUT on the other hand DJ Adams is very correct; Jabber should be used as a
transport layer i.e. JAM etc.

So what I see is a diverging interest in Jabber! 

1) The application wrapper capabilities ("The craftsman...")
2) The infrastructure as JAM.

Today Jabber does both and all new JEPS try to cover both! 
This duality is quite confusing and lead to phrases like: "Oh Jabber can be
used for everything...". In my ears that is too overwhelming!

My question is: Shouldn't Jabber NG reflect this divergence?

I.e. you could have a pure/core Jabber component. This pure/core Jabber
component should have no appliance-defined extensions. That will be the
presence and messaging protocol. 

>From this core component there could be sub components: 
1) Common instant messaging specific extensions. i.e. Alerts, avatars, white
boarding, message tone etc 
2) The integration platform, i.e. transaction support, SOAP (xml-RPC) etc. 

Lars Nilsson.

On Tue, Apr 02, 2002 at 10:58:46PM -0600, Thomas Muldowney wrote:

> 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

I care. I hate bloat, I don't like the fact that we're moving towards
such a 10 in 1 wrench.

I've always maintained that a piece of software should be designed for
the job, not designed for every job. I know it's perhaps a silly 
example, but look at sjabber. While it's not everyone's cup of 
tea, it's an extreme example of 'focused' application.

This idea of course extends into the 'stub' idea, using Jabber as a
transport layer for facilitating cross-NAT and other types of app to
app communication.

> So my question is, how much would people accept in our new protocol
> extensions?  Can we start to incorporate XPath safely (I doubt it),

I am not a 'proper' client developer, but there'd be even less chance
of me becoming one the more complex the requirements on clients were.

That said, if XPath, or whatever, is necessary for a particular 
application of Jabber, then by all means use it at the client end.
Just don't make it a requirement for all clients. 

That's my take
Standards-JIG mailing list
Standards-JIG at jabber.org

More information about the Standards mailing list