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