Re: [JDEV] Concern regarding transport overload..

[Jeremie <jeremie@jabber.org>]

> 
> 	How many 'transports' are we going to have on a basic server.  I think that
> a basic server should be able to support several of the things that we've
> all said would be best in a module, but I'm concerned about people needing
> to run 10 DIFFERENT transport programs to supply this functionality.  Would
> it be possible for the basic jabber.transport to be able to provide these
> abilities without needing to run all of these transports?

Ooohhh... I see a minor confusion here :)

A 'transport' is quite different than a 'module'.  The transport is a
completely seperate 'server' process that understands the server <->
server Jabber protocol and can translate to another messaging service OR
serve a special function/purpose.

The Jabber transport, which is just a normal transport, is what the Jabber
clients connect to, it's where most of the work happens.

A 'module' is an extension to the Jabber transport, similiar to how
modules work in Apache.  The modules inside the Jabber transport are what
handles most of the end-user server-side intelligence, making decisions
for the user and storing their data.

There will probably be at least a few transports installed/running with
any installation, mostly to supply the transparent connectivity to
ICQ/AIM.  But it will work just fine with only the one Jabber transport.
I'd love to see a very rich pool of transports available for those that
want different functionality.

With modules though, they are compiled in and any installation will
probably only use a few, the ones that have the functionality they need.

Either way, lots of transports and lots of modules is a good thing, not
all installed at once, but available to cover different areas of needs.

> 	Now, don't get me wrong, I LIKE being able to throw everything in modules.
> What I'm concerned about is the one or two executable ISP installs that have
> been mentioned..  Any ideas on how we can have the best of both worlds?

I'd like to actually have a completely different codebase(sharing the
common libs of course) to handle the special ISP server, one that is lean
and requires no setup/config, and that is limited in functionality
available. If they hit a point where they want more functionality,
upgrade, but this gives them an easy way to try it out and make it
available NOW without worry.

It wouldn't be that hard of a build to do, but it would be a forking off
of the main codebase, and I'll wait till that main codebase is
foundationally stable and fairly complete before doing so.

Jer