Re: Build system
* Rocco Rutte <pdmef@xxxxxxx> schrieb:
Hi,
> >I really like to get some steps further. Once the mailbox handling
> >is an independent library, people can write their own drivers/backends
> >for a lot of things, ie. RDF. This even gets better, if we also have
> >posting stuff in this framework, so its easy to plug in adaptors for
> >certain forums, nntp, etc, etc.
>
> Beware: it's not _that_ easy. There already is the vvv.nntp patch and
> while mail and news article formats are close, that patch is a mess. It
> requires _far_ more than just a mailbox driver. For example, mailbox
> drivers are used for incomming messages... but once you have RDF and
> feeds and want to post commits, you also need a different output driver
> (like libcurl and HTTP put or whatever) (and a framework for that).
That would all be hidden behind the mailbox framework.
We could start like that:
IMailbox # mailbox interface
: OpenPost () -> IMailPost
: OpenMailboxEnumeration () -> IMailboxEnumeration
...
IMailPost # mail post interface
: SetDestination( Address addr )
: getDestinationType() -> DestinationType # which header to show ?
: SetHeader(String hdr, String content, bool append)
: SetContent(String text)
: SetFraming(FramingType t) # set to mime, ie for attachements
: AddFrame(MessageFrame f) # add another message part
...
> I really suggest looking at vvv.nntp for areas you need to look at and
> keep in mind that it violates standards in many ways, i.e. it's not even
> complete (the article formats for mail and news differ slightly though
> they're pretty even).
hmm, I'll have a look at it as soon as my schedule allows ;)
> >Of course this is an larger project, and I suggest the following way:
>
> >1. define an clear API for the client side of this frameork
>
> Now we already have the mx_* functions defined in mx.h. Besides a few
> places (like in buffy.c the code checking all mailboxes for new mail)
> only the mx_* functions are used.
Ok. This would be a good start. I'd like to have this as interface between
the actual mailbox code, while in its backend it shall be choosable at
buildtime between old style an the new messaging framework. For this to
work, we of also course need to have the posting code behind this interface.
<snip>
> >I'd like to design the interface of this new mbox library in the
> >spirit of directfb's interfaces. This seems quite stable and robust
> >to me.
>
> This is not really easy as there're many other parts getting in your way
> very quickly. For example, if the mailbox drivers were in a separate
> library, we'd need a way to handle config options used in there,
> configure that library at run-time with things like error reporting
> callbacks, etc.
hmm, we have to split the mbox stuff of all other parts off the rest
and move it into this library, ie. move the config variables there and
add an function which does the config parsing for them. So the mbox
handling gets a real (mostly independent) subsystem.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@xxxxxxxx
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------