[JDEV] jabber server+client as a single mutiprotocol IM application

[Timothy Carpenter]

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

fredbloggs at mylocalhost.co.uk

but as the server will be connecting to e.g. publicjabber.com, the server
may, for example, munge the username to

fredbloggs at publicjabber.com

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" <theraven at sucs.org>
wrote:

> The main problem I see for this, is that this would only work for people
> with static IPs.  A jabber address is username at 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, "Евгений Филиппов" <joxy2000 at mail.ru>
>> 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
> jdev at jabber.org
> 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