Re: modules for F2 (was: parabellym)

[Jany E. <je...@us...>]

> 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.

> the logic of services will be implemented in SM, too, and this module

> 6. SMTP back-end.

SM, SM.. huh, kinda data base, yes? I don't think it really matters
whether data is dynamic or static (per-restart saved). it might be
config otherwise. any data'd be saved, though, some frames might be
stored as a dynamic structures for the blast access.

I also think SM'd deal with some real DB. this way, it becomes a
data-server, as you once said. and it sure should be xml-based.

especially in context of such amazing back-ends as http or smtp. which,
by the way, are dozens in future.

it comes so, internal modules use SM to store/get any data. SM's their
gate. though, something from the outside (like http back-end) adds
data to the storage with other gate. imo, the wise usage of xml, -
heterogeneous system comunications.

from the other side - any DB is obvious. any _real_ storage in fact.
SM could also be. we only provide different interfaces, then. I'm not
sure, your thoughts?

as about http back-end as is, - it may take less than two days to be
ready. nothing special, you know ;)