On 10 Feb 2007, at 14:28, Guenther Noack wrote:
It's definitely very useful for a pre-installed Etoile system, a
Etoile
distribution or the Live-CD, as it means we don't have to rely on an
external Jabber server providing these transports and we can assume
everybody on the computer has access to Jabber.
I'm not convinced we should be supporting proprietary IM protocols
out of the box anyway; the protocols are closed so we are relying on
people reverse-engineering them for them to work. If they protocols
change and things break, then we get blamed. If we push XMPP, then
if things break then it's our fault and we can fix them.
How lightweight are those Jabber servers?
Depends on the server. I run Jabberd2 (eJabberd is better, but
Erlang is not so well supported on OpenBSD). Ps says it's using
about 21MB or RAM (negligible CPU load with about half a dozen
users). Of this, 3MB is the server-to-server component, which
doesn't need to be running for a single-user system. Another 4MB is
the perl script that monitors the other components.
The transports, being Python programs, are a big heavier. The MSN
transport weighs in at about 13.5MB with the AIM transport taking 24MB.
Does it make sense to run one
at system startup on each machine? Running many network services by
default also means open doors for attackers when security related bugs
are found in those services. The Apple solution to this problem is
that
many network services come pre-installed, but they are turned off by
default.
The default configuration of jabberd2 does only binds to the loopback
interface, which is relatively secure (i.e. local attackers only).
Enabling server-to-server communication makes the system a lot more
useful, but we could easily have it off by default.
For user-to-user communication within the bounds of the computer, I'd
actually prefer the UNIX talk protocol. Even if it's a bit older and
less sophisticated, it provides you with user-to-user communication
without relying on a daemon.
The UNIX talk protocol is not much more than a pipe with a little bit
of glue for initiating sessions. As such, it doesn't really give us
much more than a pipe does. We can't send rich text, for example,
and we can't use it as a transport for arbitrary objects as easily.
For communication on the same machine, I would be inclined to suggest
that things go directly via CoreObject, without any extra stuff.
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
