Re: api and tagging
Mark Bronstein <bronsteinlaw <at> gmail.com>
2011-01-02 17:36:25 GMT
My project is still in the planning stages and I will keep this info in
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.
> 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
> 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.