Re: FEATURE: Smart Folders? [WAS: Re: [Evolution] FEATURE: Mailing List Folders?]

[Not Zed <notzed ximian com>]

Hmm, this bit about the smart search thing.

One problem is mapping evolution searches to some remote search syntax,
which of course might change from server to server, right?

So it might be quite hard to implement and difficult to configure.

We dont have a generic per-folder configuration mechanism either, only
per-store :-/

> On Tue, 2002-05-21 at 15:56, Not Zed wrote:
> > But NNTP isn't usenet, its just used by it.
> >
> > Various groupware servers use nntp or something like it for 'group
> > discussions' still.
> >
> > I think trying to wrap some web archive or something else in something
> > not nntp is just unwise.
>
> I'm willing to agree, but I have a question: mailing list archives are
> usually in mbox format; is NNTP able to deal with that, or will there
> have to be some conversion or shift? 

Yeah it'd need a gateway.  But that can easily be done through the
mailing list exploder ...  instead of just archiving to mbox, you
archive to nntp.

mbox at the top level is extremely trivial to parse (i.e. into separate
messages - search for "^From "), and the resultant rfc822 message
envelope trivial to convert to news format.

> If it's the latter, then NNTP will likely be the kiss of death on this
> as it's grossly inconvenient to the maintainers of the mailing lists and
> to their users who currently download the list archives for their mail
> clients' use. At which point the idea of an anonymous read-only IMAP
> server becomes interesting after all.

Ok, here comes some disjoint ramblings with no particular conclusion ...
(head isn't working terribly well today - damn rubbish truck).
 
Well, imap servers can also serve news using IMAP protocol.  This is of
course another option (and possibly better, e.g. server-side searching,
etc, although it scales differently because it has to handle more cases,
and you can't do client side caching as efficiently either).

Evolution doesn't handle read-only folders either ... (although it
probably wouldn't be terribly difficult to add it to camel).

Thing is, if you setup an archive, you have to pipe it through some
program, e.g. mhonarc (or whatever, for a web archive) or a local
delivery address to some script that makes it _available_ somewhere. 
Piping through a NNTP gateway isn't really any harder than that ... even
if it is maintaining another server (which is no harder to maintain than
say, apache, anyway).

Sure - you could just use, webdav or http to a remote mbox, and just end
up copying it locally.  But do you really gain anything other than a
coding headache, and having to duplicate most of the functionality of a
real nntp server anyway (esp for stuff like data replication and load
balancing).

I guess you could just use the mailing list stuff, and subscribe your
mirrors to it, and just feed those folders to an imap server to feed as
a shared folder to whoever wants it, assuming the server can do that
(but that'll probably still need additional work).  Get scalability by
having multiple servers and shift the delivery/replication burden to the
mail system.

I guess - what i'm saying is that its not really a client problem, but a
server one :).  And whatever server solution you chose, many clients
could already support, since the existing protocols (e.g. imap or nntp)
should probably be sufficient, with some slightly different tradeoffs.  

Writing a whole new protocol (even 'http files of mbox format at
location foo/bar' is a protocol) for servers & clients to implement just
sounds like alot of hard work reinventing the (same) wheel.

 Michael