post TB 3.1 mailnews backend plans
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
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) .
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
5. The ftvItem approach: this would require managing a lot of UI
code, so it is probably only suitable to the more exotic account
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.
 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
News submodule owner
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning