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
