jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: Re: using jackrabbit to store email with meta-data
Date Mon, 17 Jul 2006 20:48:56 GMT
On 7/14/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 7/13/06, robert burrell donkin <robertburrelldonkin@gmail.com> 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

Mime
View raw message