Javelin
Context
Different people like to communicate in different ways. Some people love
USENET, others much prefer a web interface, yet others are a fan of more
'event-based' systems like mailinglists.
Goal
Javelin is (a design for) a discussion system that allows users to take
part in one discussion though the interface that *they* prefer. It should be
possible to add new interfaces relatively easily. Right now we're targeting 3
interfaces:
- an interface that looks like a mailinglist
- an interface that looks like an NNTP (as used on USENET) server
- an interface that looks like a web forum.
Sugar might be:
- output-only RSS interface
- non-web-based client/server interface
|

sf.net project page
|
Overview
The message data is stored in a central database, that can be directly
read by the interfaces. A set of tools/libs, called the 'Core', should be
used to manipulate the database. This 'Core' makes sure that, for example,
when a message is posted to the web forum, it is also sent out to the
mailinglists.

Terminology
- 'Message' - maps to a mailinglist or newsgroup posting, or web post.
- 'Thread' - maps to a thread (nnpt/mail) or topic (web).
- 'Group' - maps to a subnewsgroup or subforum. Not found in the mailinglist interface.
- 'User' - generally, you must sign up to be able to post. When you've signed up, you can use your login/password to post on all interfaces. Part of your configuration is whether you want to recieve messages from the mailinglist interface.
For the time being, one installation of Javelin maps exactly onto one mailinglist in use. In the future, this might be extended, to allow for multiple lists (e.g, developer and user) on one Javelin-installation. Those lists would map onto seperate newsgroups or onto seperate web forum 'categories'.
About Groups: there is always a 'general' group. Messages coming in over the mailinglist go into that group by default. Later, moderators should be able to move threads to other groups (but not other lists).
The Database
In the database, a message is stored in 'rich text'. The core has API calls
to convert rich text to plain text. Currently, there is no difference between
'rich text' and 'plain text', this is a feature for later.
The current database layout design is here (in CVS).
Overview
- The Core
The Core must be called for actions that might have implications for other implementation
than the one making the change. Currently implemented functions:
libjavelin.i
Planned are things like adding/removing users, regrouping/reparenting messages, etc.
- Helper parts
- Spooler
Adds all messages in mbox files in a 'spool directory' to the database. Mostly done.
- MBox importer
A lot like the spooler, but also creates a group and fixes initial threading.
- Interfaces
- Mailinglist
Consists of a 'handler' and a 'sender'. The handler is basically the spooler above, but should scan for things like spam, viruses, out-of-office replies, mail loops, etc. first.
Attachments/uploads should not be allowed. A pastebin is/should be good enough.
Other files can be sent over in private email.
The mail sender is a program that accepts outgoing mails in
/usr/lib/sendmail-like format. When a new message arrives, it is passed on to
the 'mail sender' which sends it out to all users.
- Web Forum
Obviously doubling as online archive, including a search engine
Users that do not require mails from the mailinglist interface can request to
be mailed seperately for certain Threads.
Implementing polls isn't planned.
This will probably be the main interface for moderators to remove unsuitable
messages from the database.
A 'reply to user' functionality might give subscribers the ability to write
emails to authors of messages (without directly giving away that address).
- NNTP interface
I have no experience with how USENET works. Right now I think of Javelin as an
isolated NNTP server that does not communicate with others, and requires people
to sign up for write access.
I see no need for publishing the authors' email-adresses on the Newsgroup. At
first, i think just showing the username should be enough. If someone insists
on sending someone a message in private, he should use the 'reply to user'
function of the web interface.
Maybe a footer should link to the web interface.
Status
See that Status page
Links/references:
Regarding the whole system
For the nntp plugin
For the mail plugin:
Comparisions
Javelin might sound a lot like GMane.
I find it hard to say why, but I never really liked the feel of GMane.
It might be because it clearly favours NNTP whereas I think the
interfaces should be equally important. Maybe it is because GMane
thinks Big. Javelin is aimed to simply having one installation per
project, where a 'project' could be pretty big. GMane is aimed at
serving hunderds of big projects on one installation. Both have their
pro's and con's, we can happily live together.