[JDEV] Best way to drive Jabber adoption?

[Timothy Carpenter]

On 15/6/03 6:32 am, "David Waite" <mass at akuma.org> wrote:

David,

<quote editor on>
> 
> A personal server still does not account for how alien the existing
> 'legacy' protocols are.

I have never suggested otherwise.

>Even if you map the wide range of message formatting options to
> xhtml on the inbound, you would still need a way to represent the remote
> user's formatting capabilities to the Jabber client.

Could not agree more.
> 
> Once you start tightly coupling protocol for talking to IM users based
> on their network provider

Never suggested that.

> 
> The reason that the transports aren't considered by many to be the
> 'focus' of the jabber community...

> The limited amount of effort the community is capable of can either be
> focused either on supporting existing functionality in legacy systems,
> or we can add genuinely new functionality like group calendaring and
> events. 

This is understood, but I have seen so many groups moving ahead with new
functions and not supporting legacy issues (and I strongly disagree with the
term here) only to find the need to keep the old running becomes a vital
need, and they have lost much the knowledge.

I truly do not want to see Jabber caught in that situation!

> -David Waite
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev

Other messaging providers have the concept of a daemon which can provide a
'local loop' of messaging capability at the node for immediate turnaround of
messages to other entities also using the protocol on that node.

This is partly the drive behind this suggestion (zero conf server at node).

Maybe I am being too early for this and/or transport support is not a
co-driver for it for the community, but I will benefit from such a daemon
and will be moving towards that for my work. I suppose a JEP is then in
order, or maybe I am alone in this need?


Thanks
Tim