Thanks, Paul. My project is still in the planning stages and I will keep this info in mind.
Best regards, Mark B. On 1/2/2011 6:52 AM, Paul J Stevens wrote: > On 01/01/2011 05:36 PM, Mark Bronstein wrote: >> Thanks, Lou and Happy New Year to you as well. >> >> Glad to hear that the potential I am hoping for is in the works. I have >> never used dbmail but I have always been impressed with its well >> designed deconstruction of emails into their constituent parts for >> efficient storage purposes. >> >> If the mail store could also become a useful backend for non-imap >> access, this could allow dbmail to remedy the weakness currently found >> in many many existing crm and case management applications: allowing >> incoming and outgoing emails (and their attachments) to be fully >> integrated as first class objects into the application's data structure. >> >> I'm looking forward to hearing more about how and when these two >> functions (tagging and an API) will be available for general use. > Mark, > > the http api is not finished. Mostly incomplete, but also not as > REST-full as I thought. > > Concerning REST: the REST definition uses GET for read, POST for create, > PUT for update, and DELETE for removing entries. DBMail's http currently > uses GET/POST only! Using POST for updates and deletes. Maybe that > should change to better align with REST conventions. > > Concerning functionality: > > some things there already: > > list users, list mailboxes per user, create/delete mailboxes > create/delete messages in mailboxes > fetch messages and message headers > > some obvious things missing: > > create/edit/delete users > edit message meta-data (flags and labels) > searching mailboxes > > adding these - and fixing the REST api along the way - is trivial. These > functions are well defined in the code base, and only need to be exposed > in the http layer. > > If people are willing to help me out with testing and discussing these > issues, I'm more than happy to work on this and finish it in the 3.0.x > series. > > Apart from this I'm sure you and Lou can come up with non-trivial things > to add. If and how they can be added depends and the feature. Basically > anything that accesses multiple mailboxes and/or users is terra > incognita. Multi-mailbox operations are well described in several imap > extensions, multi-user operations would be logical extensions of those. > But no such functionality exists in the current code. Adding > multi-mailbox imap extensions (and http entry points for them) would > obviously take longer - depending on time, resources and proper > motivation. However, they won't happen in the 3.0 series, but may well > be added to the 3.2 targets - still to be determined. > > > _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
