> Jabber suffers from central management... its distributed like email,
> but a central server still exists that is managed by an admin. This
> constrains the users to what the admin implements on the server. By
> using jabberd on localhost, it moves under the user's control and
> becomes more p2p-ish...
delivering mail requires a central server also (determined
by MX-record in DNS). so it is much like email except that
the domain part of the jabber-uid is directly resolved
(no JX record in DNS :-)
i think there is only one clean way to become most indepent from protocol
details. jabber is on the right track providing a universal,
extensible *data structuring* cabability so that programs
have a common *data representation and exchange language*.
You still have to program the code (on both sides) to
understand the structured data streams. Changing
on one side might lead to problems on the other side.
plus it is very difficult to do server stuff on the client
side (an important p2p idea) which would also help to
decentralize communication and make it harder for AOLish
companies to rule.
the solution: transport code that provides the actual interface and
does the wire protocol much like the now server-side components.
use the existing xml infrastructure to send and receive code fragments.
sending python or java or even c-libraries is not an unsolvable problem.
nowadays the bigger problem is security.
just executing foreign code on your machine might not always be the best idea.
but then, distributions like debian do it: select code to be installed,
download, execute/use. why not do something similar for jabber-services? Due to the
fine nature of jabber-xml-streams this is a meta-extension which can coexist
with the current jabber-stuff.
Do these thoughts sound reasonable to you?
holger
--
[EMAIL PROTECTED]
corba transactions project: http://xots.org
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
