modules for F2 (was: parabellym)

> The nightly 
> script runs this test after rebuilding the source tree, so it should be 
> seen here at midnight MSD, if the nightly script does not break.

It is broken.  I can't do anything about it now -- the CVS repository is 
damaged, I'll be taking actions this night.

> This means that the infrastructure for other projects (namely F2) is now 
> ready for being used.

I have once promised to write a list of required modules for F2.

1. Networking stack.

We obviously do not want to deal with parsing the RFC1459 protocol in 
each module.  So, this will be the module that maintains network 
connections and deals with the RFC1459 protocol (split messages to 
attachments and combine attachments to messages).  It will accept 
incoming connections and establish outgoing ones (using SRV only).  It 
will perform hostname resolution and reverse mapping check for incoming 
connections.  I have written a documentation for this module, proposed 
name is "cetb" [2].

The proposed version only parses the protocol and sends one callback 
message for all events on a connection.  Kind of a dispatcher.  The 
proposed version is kind of a wrapper around RASCAL.  However it can be 
enhanced to send a message per command to allow handling different 
protocol commands by different modules.

I do remember all previously circulating talks about having a more 
generic networking interface which would not be directly connected to 
the RFC1459 protocol, but I think the proposed idea of building a 
message from a set of attachments is extensible enough.  The module can 
be easily modified to work with a custom binary protocol, which would 
send every attachment as a true Pascal string, instead of using the 
RFC1459 schema.  I can not imagine a higher level of extensibility right 
now; even named parameters can be implemented without much effort 
(however I think that that would hadrly be efficient on high-scale neworks).

2. Storage maintainer (SM).

I still think that separating the data worths separating from the 
unrelated logic.  One module would maintain both the static (saved 
between F2 restarts) and dynamic (in-memory) data.  It would use disk 
storage when necessary and it would maintain consistency of the data.

This means that SM is, actually, the main module which resembles the 
most important part of the current ircd, but which is freed from 
interface operations.

The module would send various notification messages when things change, 
so that other interesting post-processing could be done without 
modifying the SM code.

3. RFC1459 protocol handler.

This module would handle all standard protocol commands like NICK, USER, 
JOIN, PART and so forth.  Nothing special.  For example, the handler of 
the JOIN command would split process the parameters and split 
multi-channel joins into series of atomic joins which are served and 
validated by SM.  If SM reports a failure, all necessary actions are 
taken and events are reported by the JOIN command handler.

4. Services.

In F2 services are merged with the server, so the interaction is not 
performed by by sending messages, but with NICKSERV and similar 
commands.  Or otherwise, not yet sure.  What is already known is that 
the logic of services will be implemented in SM, too, and this module 
would be yet another protocol parser which enables several commands and 
does not really implement anything new.

5. HTTP back-end.

We want to register nicknames using a web site only for the purpose of 
implementing a Turing test and otherwise introduce the user to the 
services we provide and other spam.  This module would not directly 
interact with users; it would only authenticate the sender and process 
specifically crafted requests.  The sender would be the web site that 
deals with the user interface and contacts the back-end.

6. SMTP back-end.

Changing passwords requires email confirmations ("use this activation 
code to change your password").  We could also send offline messages to 
the user's email address as they are stored.  This would also require 
SMTP.  The interface would be quite simple: receives the formatted 
RFC822 messages and sends it.  Deals with the SMTP protocol.  Simple.

That's almost it.  Tell me if I have forgot anything.

=== References: ===

1. "Perspectives of Faerion"
    <http://hex.forestnet.org/feed/dev.html.var#9>

2. "Faerion, iteration 2.  Cetb." -- a documentation on the networking 
module.  It also serves as a proposed standard for Parabellym module 
documentation.  Reviews welcome.
    <http://faerion.sourceforge.net/doc/parabellym/mod/cetb/>



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
-------------------------------------------------------
Discussions in this list are held in two languages: English and Russian.
When replying, please use the language that the sender of the original
message is guaranteed to understand, or use English.