Mailing List Archive

Re: [Dbmail] db_get_message
Anton,

Anton Nekhoroshih wrote:
> I think creation function db_put_message (id) and db_get_message (id)
> will considerably simplify operation with various databases as other
> syntax SQL of inquiries is identical.

I very much agree. The execution paths for inserting and retreiving
messages are currently very complex and therefor error prone. I think
Ilja's problem in tracking down the parse error just proves this point.

Defining a cleaner and more abstract api will allow new applications and
better versions of the current applications to be better maintainable,
will make it simpler to develop new applications (ie dbmail-nntp,
dbmail-admin, dbmail-admin-gnome, dbmail-xxx ?) that will not need
rewriting when changes in the storage engine occur.

This thread should move to dbmail-devel.

--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl
Re: Re: [Dbmail] db_get_message [ In reply to ]
On Sat, 2004-04-17 at 10:25, Paul J Stevens wrote:
> Anton,
>
> Anton Nekhoroshih wrote:
> > I think creation function db_put_message (id) and db_get_message (id)
> > will considerably simplify operation with various databases as other
> > syntax SQL of inquiries is identical.

I do think we should change the names of the functions to
db_put_message_contents() and db_get_message_contents() (or something
similar) to avoid confusion with other functions.
>
> I very much agree. The execution paths for inserting and retreiving
> messages are currently very complex and therefor error prone. I think
> Ilja's problem in tracking down the parse error just proves this point.
I don't really know if this solves that problem right away. I think the
current problems are caused by the complex handling of input from the
network stream. Sometimes I'm wondering about how much simpler things
would be if we were using a language that is better suited to working
with strings etc....

>
> Defining a cleaner and more abstract api will allow new applications and
> better versions of the current applications to be better maintainable,
> will make it simpler to develop new applications (ie dbmail-nntp,
> dbmail-admin, dbmail-admin-gnome, dbmail-xxx ?) that will not need
> rewriting when changes in the storage engine occur.
Agreed.

Ilja