[jdev] Local proxy for multiple applications
aliban
aliban at gmx.net
Fri Apr 21 11:31:23 CDT 2006
Hi Michal,
once I tried to introduce such an application/proxy for jabber. I worked
on for a very long time whatever I did never get any positiv feedback
and therefor I did stopped spending more time on it. :/
If you are interested:
http://wxxcd.sourceforge.net/
basically the "daemon" should compile on linux, too.
if you are really interested I would try to find the last(=current)
source I wrote. (I am not sure if the source in cvs is the latest)
Well, it was already working :/ but nobody wanted to develop an
application on top of it :(
regards,
you may contact me via jabber
edrin at jabber.org
Michal Vaner (Vorner) schrieb:
>Hello,
>I was thinking this way: There are apearing some applications that do some
>tasks and their primary purpose is not comunication. However, they comunicate
>using jabber. (inkskape for example, if I remember well). Users want games in
>IM clients, which has nothing to do with IM. UNIX filosophy tells to separate
>different tasks into separate programs. So yes, it would be possible to
>separate the games into different programs, which would be just called from
>the client with right info (where to connect, which user try to contact and
>everything).
>
>However, this would mean the game mush have full supprt for things like XML
>parsing, SASL, TLS and everything. It would mean another connection to server
>as well, which would mean more load on server, need to keep the connection
>using whitespace pings (which means more pings with more connections) and
>another resource appears for other users.
>
>So I was thinking about something like is X server. On a user login, it would
>start and connect and provided kind of user proxy for all his application,
>making it only one connecion and making the life for applications a bit
>easier by handling the SASL, TLS, transparent merging of more accounts
>together, and more extensions like file transfers, jingle and so on. It would
>mean even transparent handling of history, regardless if it is server-side or
>client-side, support of new features for application which did not have it
>before (like it would be possible to add encrypted sessions to all
>applications without them knowing about it, for example).
>
>Another advantage would be, if the graphic frontend crashed (and the graphic
>application tend to do so more oftenly then simple text ones, I don't know
>why), you would not lose your last messages and messages got on the last
>moment, you could just start the app again and it would get them, and other
>users would not even know something happend to you.
>
>Of course, the design would need to be done more properly, but I wanted
>someone to comment on this a bit, if it is a good idea. I'm sending it here,
>because I think it has nothing to do with standards, it is just another way
>for a design for client software. If you think otherwise, I appologise and
>would move it to better mail list.
>
>Thank you.
>
>
>
More information about the JDev
mailing list