[jdev] Re: An idea for a Jabber transport

Francesco Delfino pluto at tipic.com
Wed Aug 4 03:16:55 CDT 2004


Hi,
Some time ago (about a year), I had the same idea: build a transport 
framework where GAIM plugins could plug in.
I started inspecting the GAIM code, and to say the truth, it is not well 
written for server development, in the sense that user interface 
elements and "protocols" interact very deeply.
Also the plugin abstraction layer looks not so much "independent" from 
the undelying protocol (if I remember well, every protocol is mapped on 
the original interface written for AIM).
To make the whole thing working you:
- should be a very carismatic person so to convince GAIM developers to 
re-ingegnerize their code for sake of jabber.
- actively partecipate to their mailing lists, so to point their efforts 
to common goals
Also the JSF (== the sponsoring companies) could give some money to the 
developers (you (?) and the main GAIM developers) in the form of prize 
for the work done.

In the past, I looked at an efficient way to assure transport 
development and fixing but, at this time, I did not find a good solution 
for several reasons:
- most transport are one-man-projects written in spare time for their 
own delight
- you need a very good programmer to write transports, but good 
programmers often become afraid to deal always with the same tediuos job 
of looking at the mailing-lists about the protocols.
- from an economic point of view, if a company has a programmer so 
skilled to do transport maintainance, it is better to "invest" him in 
some more lucrous activities (for the company)
- form a legal point of view, transport develoment is not "clearly" legal.
- at last, I think end users did think transports so appealing as in the 
past either because computers are becoming more and more powerful (so 
taking 4-5 IM clients open does not waste resources), or because now all 
the major players (but Microsoft) have the "original" client available 
for most OS.


Trejkaz Xaoza wrote:

> Jabber transports.  At least one transport (Yahoo) uses bits of code from
GAIM already.
> But it uses only fragments of the code.  I started wondering whether it
could use the
> entire plugin, such that a Yahoo plugin from GAIM could be dropped in and
dynamically
> linked from the transport.
> 
> I was thinking it could be based on JCR, and I could borrow code from the
Yahoo transport
> (as an example of how to use JCR) and GAIM (as an example of how to load
and use their
> plugins).
> 
> Advantages?
> 
>     - There might be less code in the transport, and less code is easier
to maintain.
> 
>     - There would only need to be "one" transport, which would work for
all protocols
>       for which GAIM has libraries.
> 
>     - Updates when idiots like Yahoo change the protocol without warning
anybody would
>       be solved sooner, since GAIM tend to get the fixes to any given
protocol before
>       the equivalent Jabber transport.
> 
> Since the general gist is "less long-term development time", the idea here
is that once
> the basics are working, it might make it easier to add new features,
rather than simply
> being forced to play catchup all the time.
> 
> Disadvantages?
> 
>     - Possible memory consumption issues.  GAIM can run multiple
connections of the same
>       protocol, but how much memory does each connection consume?
> 
>     - Any other disadvantages?
> 
> I would be interested to hear people's ideas on this, or whether someone
else has already
> had the idea and is already working on it so that I can stop thinking
about it.  Because
> it's probably consuming more time than it should, and is detracting from
playing with my
> new toys. ;-)
> 
> TX
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> https://jabberstudio.org/mailman/listinfo/jdev

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.730 / Virus Database: 485 - Release Date: 28/07/2004
 




More information about the JDev mailing list