On 7/14/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 7/13/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> the folder metaphor is widely used today. most clients use it extensively.
> many mailing list archives are also organised in hierachical fashion. so,
> integrating with existing email clients means supporting a hierarchy.
You're right. My POV was more of email as a flat sequence of incoming
messages, with any threading, foldering, labelling, etc. hierarchy
structure as an add-on metadata layer, but of course it would make
sense to use one of those hierarchies as the primary structure for a
JCR mapping.
i started from that POV as well. filtering into folders really isn't
anywhere near as useful as tagging with meta-data that can then be
processed in flexible and sophisticated ways.
however, the more i look into existing ways email is used, the more i
think that foldering via a primary node hierarchy which is not
meta-data would be useful. foldering is really pretty central to the
most common ways email is processed today. supporting primary
foldering would allow compatibility with existing clients and
processors.
for example, the MTA for a machine usually supports multiple users.
so, one basic hierarchy is a different node for each local user that
receives mail. another example is filtering into folders using (say)
an RFC 3028 implementation.
some of this seems a little orthogonal to the meta-data. lots of users
just like to move emails around. clever clients that would suggest
appropriate meta-data would be very cool but for now i'd settle for
being to connect from clients who are just looking for a simple
IMAP-stle foldering system.
> one POV is that everything is meta-data. presenting meta-data query results
> as folders would be powerful.
Agreed. JCR supports both references and saved queries for efficient
access to a configured subset of nodes within a repository.
great :-)
> (until i looked into it) i didn't realise that jackrabbit supported webDAV.
> this is interesting since i think that using a webDAV email vocabulary
> (analogous to calDAV) as an alternative to IMAP has some real advantages for
> the kinds of application i'm interested in. there's some interest over at
> the IETF on this subject.
Sounds interesting!
good :-)
IMAP is not RESTful and is very difficult to implement securely. HTTP
has many good properties for sharing over the internet.
AIUI the idea of developing an alternative protocol using webDAV has
been thrown around previously but no real momentum developed. the
webdav group operates openly and there's interested in pushing the
idea forward.
> would jackrabbit be able to provide a reasonble prototyping environment (in
> the sense of being able to try concepts without a lot of ceremony for email
> over webDAV)...?
There has been discussion about generalizing the WebDAV implementation
in Jackrabbit. Some parts are already quite general, i.e. the
Jackrabbit WebDAV server already provides two alternate (file- and
item-based) views to the repository content. Prototyping an "email
view" would be an interesting challenge.
great :-)
http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JulSep/0016.html
> i'd be very glad to help out if you want to develop the port on list but i'd
> like to try to triangulate data types with james developers (probably when
> i'm a little further on) and the ietf working group. that sound ok to you?
Sounds good. I'm also OK with continuing the discussion on the James
mailing list or somewhere else if you think it would be better.
There's a lot of JCR experts on this mailing list, but probably not
that many email experts.
i'm happy to continue talking on here at least until someone jumps in
to declare this off topic...
IMHO the timing's wrong for james ATM (releases and new architecture
happening very soon)
but i'd also prefer to start by thinking about the JCR bindings first.
so, the yukatan bindings sound like a good place to start. fancy
kicking off by starting an appropriate thread?
> which import tools?
I wrote a simple import tool that was able to pull email from IMAP
servers and mbox files and push it to a relational database using my
"Yukatan data model" schema. It should be relatively straightforward
to port that tool to use a JCR repository. The importer is available
in CVS at http://sourceforge.net/projects/yukatan, but I'd be happy to
move the code to ASF if there's interest.
a stripped down version of james is doing a good job for me right now.
i'm using SMTP on a high port for development.
i have a mini-application in mind (producing analytic reports on
incubator poblings email lists to help as an early warning sign). i
plan to use james to pull down the email from a POP3 server.
- robert
