15 Mar
2008
15 Mar
'08
11:51 a.m.
[snip]
Indeed. In the end, Watch is a tool that basically allows for collaborative
filtering of any kind of information as long as it can get in under the form
of ordered items (articles, messages, posts...).
My point was not so much that Watch cannot do email management (I'm
convinced that it could indeed bring a lot of value to the process of email
filtering, for instance by allowing a team of salespeople to filter &
classify incoming contact mails), but rather than its features set might be
an overkill for people with basic email archiving needs.
* A way of
sending emails to XWiki so they can be stored, archived and
referenced from a wiki page.
Yep, I remember some talking about this.
BTW I wonder if XWiki Watch could be used for this? We'd just need to
hook a mailbox + a POP module (or a mailing list archive reader) and
it should work just fine I think.
I'm not sure this is the most relevant way to do it.
I don't agree. What you have in mind is a simple email storage/search
facility. However leverage watch we get much more:
* The ability to tag/filter interesting mails. Since the problem with
mails is that the information is scattered a bit everywhere, I think it's
useful to be able to say that such email is flagged as containing
interesting information for example.
* The ability to reuse an existing interface with all its niceness
* Emails are just a source of information. I recall Ludovic saying that
Watch was designed to allow different input sources. For example for AFP we
had discussed using Watch to read their existing documents and presenting
them in Watch.
* The Watch Email plugin would be easily plugged onto a mailing list (by
having a watch user subscribed to the list for example). Another plugin
would be one that plugs on the email list manager (and thus can request past
emails, etc).
* When Watch gets new features added our email feature also gets features
added automatically.
* Watch can be seen as a generic tool for managing information source
feeds.
I'd rather see an email archive application that
would work this way ->
you send an email to a given address (say emailarchive(a)yourxwikiserver.com)
.
There's another option. Create a forum application to manage mails in the
same as Jive is doing it with their forum:
http://www.jivesoftware.com/products/forums/featuretour.jsp
They also support plugging in their forum onto an existing mailing list
which is great.
Since the way a forum works is very similar to the way a mailing list does,
this can be an interesting idea too : let users post from either the forum &
the mailing list, and have emails automatically generate forum entries &
forum entries being sent as emails to the list. In the end the user doesn't
care where to post from, like what Nabble offers
IMO going the Watch route would be a good thing to try as a POC or as a GSOC
since it shouldn't be too hard to do.
+1 for making this a PoC / GSoC project.
As for how to do all this, I think Anca proposed a sound way to do it :
"As for directly reading a mailbox and a mail archive, here's how we could
do it: apart from the feed reader plugin, we can have a mailreader plugin
to handle this job (and just the same, a lot of other reader plugins to
handle various types of content). It seems the right way of adding extra
content fetching powers to Watch so this is, in the end, not a Watch
specific job but more like a plugins one."
-> We could write a mail plugin (in fact I think there's already some kind
of a mail API in XWiki, coming from the mail-1.4.jar plugin, but we could
also use something like James -> http://james.apache.org/) that would
receive email and then process it towards either Watch, the Forum or any
other application (maybe using something such as this :
http://james.apache.org/mailet/index.html), to allow for maximum
flexibility.
[snip]
Guillaume