post TB 3.1 mailnews backend plans

Joshua Cranmer Pidgeot18 at gmail.com
Sat Jul 17 18:03:13 UTC 2010


  *mutters about mailing lists and archives*

Okay, replying to the document directly:

> Current Approaches, as I understand them:
>
> RSS approach - RSS inherits from nsLocalMailFolder, nsMailboxServer, 
> and implements nsRssService. It stores messages in the local mail 
> folder, and each message essentially contains a link to the rss 
> message. For simple datasources, like Twitter, this would be a fairly 
> simple approach.
>
Right now, this approach requires a small binary blob for the server 
(the service can easily be written in pure JS).
>
> Jcranmer's Web-forum approach - Allow js objects to extend the core 
> c++ objects, and implement the web-forum specific things in the js 
> objects.
>
I don't think is a viable option for the long term: xpconnect is just 
too fiddly here, and I've not managed to make a reasonably stable 
version of things yet. It doesn't help that documentation on trying to 
interact with xpconnect guts and cycle collection is completely lacking.
> Implement a library that does most of the common implementation, with 
> a pluggable mechanism for doing the data source-specific things (e.g., 
> enumerating containers/folders, pulling in messages, etc). 
I suspect this may require changes to the account loading architecture. 
Not that I disapprove :-) .
>
> Different data sources have different requirements, both at a 
> technical level, and a UX level. Some data sources need changes 
> propagated back to the server (e.g, Exchange) but most do not. Some 
> need to fully sync with the server in an IMAP-like way (e.g., if a 
> message is deleted from the server, remove it from the client), but 
> most do not. Some may lend themselves to the folder metaphor, like web 
> forums or MAPI; others, like twitter, may not. So there can't be a one 
> size fits-all solution.
>
Going forward, I see we have about 5 approaches:

   1. The current architecture: extend the server, folder, database, and
      possibly the protocol to implement what needs to be done. Assuming
      that the appropriate functions are exported properly, any
      extension willing to be a binary extension could be able to do
      this. This is the most powerful approach, if you want to be
      mail-y, and current account types depend on it, so I think it
      should always be an option if you really need it.
   2. Kent's approach: delegate some methods to the core objects. This
      is similar to 1, but slightly less powerful (you can't rely on
      virtual methods to change implementation) [1].
   3.  From scratch: reimplement all of the key interfaces from scratch.
      There is nothing wrong with this, except that you would have to
      rewrite >10K lines of code. A more realistic idea is to fragment
      the interfaces between the truly needed to be implemented and the
      common library methods (so similar to number 4), but this would
      require users of the code to change their code.
   4. The library approach: we could create an interface, à la pluggable
      store, that would essentially do most of the real implementation
      of the objects. Then the library does the glue code between this
      interface and the server, folder, database, and message store
      implementations.
   5. The ftvItem approach: this would require managing a lot of UI
      code, so it is probably only suitable to the more exotic account
      types.

Like Kent said, a key step that needs to be made is figuring out the 
basic model of account types. I'm still working out my own opinions of 
this, so I am not sure I can answer this question right now. In any 
case, it seems clear to me that there needs to be different levels of 
specifying account types, from an extremely light approach for RSS to 
the heavy approach that things like IMAP would need.

[1] Well, you could make it equally powerful as 1 if you were insane and 
did a lot of vtable munging. Needless to say, it would be a rather 
fragile approach, but it seems like it might be less fragile than my 
current approach.

-- 
Joshua Cranmer
News submodule owner
JSHydra author

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20100717/0553fe5d/attachment.html>


More information about the tb-planning mailing list