<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#ffffff">
*mutters about mailing lists and archives*<br>
<br>
Okay, replying to the document directly:<br>
<br>
<blockquote type="cite">
<p>Current Approaches, as I understand them:
</p>
<p>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.
</p>
</blockquote>
Right now, this approach requires a small binary blob for the server
(the service can easily be written in pure JS).
<blockquote type="cite">
<p>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. </p>
</blockquote>
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.<br>
<blockquote type="cite">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). </blockquote>
I suspect this may require changes to the account loading
architecture. Not that I disapprove :-) .
<blockquote type="cite">
<p>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.
</p>
</blockquote>
Going forward, I see we have about 5 approaches:<br>
<ol>
<li>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.</li>
<li>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].</li>
<li>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.</li>
<li>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.</li>
<li>The ftvItem approach: this would require managing a lot of UI
code, so it is probably only suitable to the more exotic account
types.<br>
</li>
</ol>
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.<br>
<br>
[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.<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
News submodule owner
JSHydra author</pre>
</body>
</html>