Maybe I misunderstand, but if the localserver connects AS the client to the public Jabberserver , then the bounce issue shall not occur, as the public Jabberserver only sees a client c2s connection, not an s2s and will spool messages as for any other offline client (see below).
The means here , as I see it are to draw in the other transport plugins locally. On occasions this makes good sense as it abstracts transport and connectivity needs from the public server and allows the localhost to manage their own aliases privately. Downside is that connecting via any other locale from the localhost will not provide the transports. However, as I mention, this has uses in a world where one client connection provides the channel for many. Not important in chat, rooms, presence etc, (admittedly most people's focus) but when it comes to data distribution and pub-sub it can have uses. It in no way replaces other forms of connection, just that it is a useful extension to the way things can be done. As for DNS, the client's username to the local server may be [EMAIL PROTECTED] but as the server will be connecting to e.g. publicjabber.com, the server may, for example, munge the username to [EMAIL PROTECTED] when it connects to the 'c' side of the c2s channel on the public server. Alternatively the translation can be arbitrary...as the local client can have a generic name and only allowed from localhost, and tables used to convert into the various public names, all different, used on yahoo, MSN, Jabber etc. Tim On 24/01/2003 1:37 pm, "David 'TheRaven' Chisnall" <[EMAIL PROTECTED]> wrote: > The main problem I see for this, is that this would only work for people > with static IPs. A jabber address is username@server's_DNS_entry. If > you're on a dial-up, you won't have a static DNS entry, so people will > have to add you to their roster every time you log on. Secondly, if the > server is only running when the client is running, then when the client > is offline, messages sent to the user will bounce. > I suppose that there's no reason why you couldn't register a jabber > account with a remote server, and run the transports on a local server, > except that you'd probably have to re-register with the trasnports every > time you ran the client (You can't use @localhost in a remote roster, > since localhost wouldn't be your machine, but the server), although this > could be automated. > > Timothy Carpenter wrote: > >> Joe, >> >> Networks that run in a ��fractal�� mode have advantages �� it I often >> desirable for a sub network to appear as a single client to the >> outside world (i.e. a local/private server connecting via c2s to the >> public servers). Thus the idea is interesting to me. >> >> Last year I formed a drag and drop jabberd on Mac OSX 10.1.5 (using >> the BSD Unix version) in jabberd 1.4.2 form. It is not a big task on >> OSX to have the client kick off the jabberd, thus providing a >> shrink-wrapped single icon implementation. >> >> Not sure how this would work in Wintel environments. >> >> Tim >> >> >> >> >> On 24/01/2003 12:22 pm, "���ӬԬ֬߬ڬ� ���ڬݬڬ����" <[EMAIL PROTECTED]> >> wrote: >> >> I had a thought: a jabber server + jabber client packaged into a >> single installer could be used as a convinient multiprotocol IM >> client. I.e., both the j server & j client will run on the same >> localhost. They may even be compiled into a single executable. >> >> >> Rationales >> >> Rationale 1. I find it difficult to find a working gateway server >> e.g. for icq, aim, msn, yahoo. So the main point is that the local >> gateways to these services will work much better, since the >> localhost does have a very little load. Here, i mostly speak >> about free gateway servers for icq, aim, yahoo. They are sometimes >> unstable, overloaded, slow, etc. The local system might represent >> a more attractive choice. Additionally, the local server will not >> become banned by AOL and other companies. >> >> Rationale 2. The system will be much less distributed, and, >> therefore, much more stable. >> >> >> Possible implementation details >> >> The local jabber server does not have to use jabber s2s, it may >> have a special transport for c2s to public jabber servers & >> services. >> >> Any local jabber server configuration tasks that are too advanced >> and/or not useful in the normal circumstances can be done at >> compile time and/or automatically at runtime, such that the >> enduser will never be able to get to these handles. >> >> >> Questions >> >> Question 1. Is there anyone who develops such a project? >> >> Question 2. Does this sound as an interesting idea for anyone to >> pick up? >> >> -joe >> Filippov Evgenii >> >> > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
