On 14/6/03 3:10 pm, "Andrew Sayers" <[EMAIL PROTECTED]> wrote:
> Tell me if I have misread, but I think your argument is that people who > are currently using multi-protocol clients will be better served by a > Jabber client plus personal server because then all the transport code > (etc.) would be based on a common code-base, instead of every client > writing the transport code from scratch. Yes - common code base would go a long way to keeping such transports up to date. > > If this is your argument, then it is based on a faulty premise. Clients > can use libraries to much the same effect, without the bloat that comes > with running your own personal server. Can we get client and transport writers to agree to a common library framework for adding components? Even if we did (!), does this not mean even more platform and language issues? The beauty of Jabber is we use XML to talk to the outside world and have components talk to the server in that fashion. Specify your XML to talk to your various transports and you have surely cracked the issue...defined a superset of Jabber! I think the way a Jabber Server allows components to connect is >a good thing< already and is something to be leveraged. We have already seen how 2 tier becomes 3 tier. <lateral thought>It may be that the existing c2s is the real problem and we can only progress multi-transport-wise with a dumber chat client specification...</lateral thought> >Also, multi-protocol clients can > support the various protocols the way they are supposed to be supported, > not "a la Jabber". To take an example I've hinted at in a different > sub-thread, MSN's only chat mode is a curious many-to-many creature, > with less features than GC, but more than normal message-passing. Surely this suggests that client-side is better for MSN transport? > Some people (Jabber's natural userbase) will want this Jabberified, so > it all works the same regardless of network, even if this means a loss > of features. Some people (multi-protocol clients' natural userbase) > will want things to be just like back when they were using Microsoft's > own client. This does not go away regardless of personal or centralised server transport support, but I agree that it is a problem. > > On top of that, personal servers would knock out many of Jabber's > biggest benefits, like the ability to send files between two users > behind NAT firewalls, I have suggested that the Jabber personal server presents itself to other Jabber servers as "you" on a Jabber client - a 'repeater'. It has ONLY one client privately connected to itself and is on the same host so it is not spoofing. Thus it could perform Jabber-to-Jabber file transfer across NAT firewalls. > the ability to upgrade components without users > noticing, If you really want that, then concepts such as Citrix... Having a multi-transport client is no better or even worse than a personal server. New features will usually mean new clients. > and IM addresses of the form "[EMAIL PROTECTED]" rather than > "[EMAIL PROTECTED]". See my point about Jabber server connectivity. It connects as a CLIENT to the remote server with its bastardised s2s that connects to the c2s of the remote as if it is you. > > Having said all that, I agree with you that transports need more > attention (see my other post), and that some automatic way of finding a > good (nearest? Lowest ping time? Most featureful?) server would be a > big asset. Since it's your idea, would you like to volunteer? Ha! My idea is a local drag and drop multi-transport environment. If I can get both a Yahoo and MSN transport for BSD Unix (suggestions, anyone?) then it is likely I will try as I already have a drag-and-drop Jabberd on my Mac to add them to! BTW all my puff about a multi-transport client is just to get Jabber protocols out there! > > - Andrew > Tim _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
