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: using jackrabbit to store email with meta-data
Date Thu, 13 Jul 2006 20:35:35 GMT
On 7/12/06, Jukka Zitting <jukka.zitting@gmail.com > wrote:
> Hi,


On 7/12/06, robert burrell donkin < robertburrelldonkin@gmail.com> wrote:
> > it strikes me that it's more natural to store emails plus meta-data in a
> content
> > repository such as jackrabbit rather than in a classic RDBMS.
> > [...]
> > 1 is jackrabbit really a good match?
> I think so. Although email storage is not inherently hierarchical
> (unless you opt for a folder structure), using a content repository
> does give you a set of nice features like built-in full text indexing
> and a flexible data model that would be hard to achieve with a
> relational database.

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.

one POV is that everything is meta-data. presenting meta-data query results
as folders would be powerful.

but many people like to be able to do ad hoc organization and so i suspect
that it may turn out to be cleaner to support primary folders outside the

so, a store which naturally supports hierarchical organisation is a plus.

(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.

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)...?

(i know that i'm going to need to do a lot more reading around webDAV
support in jackrabbit)

> 2 is there anyone already working in this space?
> I had similar thoughts two years ago with RDBMs, but I never took the
> idea further than creating the data model and some initial email
> importers. I looked at Apache James as a possible tool to work with,
> but the barrier of entry was too high for my limited amount of time at
> that time.

i've promised noel that i'll help out with openpgp on james so i'm learning
james anyway...

Later on I went with GMail and most of the itch was gone.

i have 5G of email archives stored in IMAP but i'm fed up of having to port
the hundreds of filters i use to organise my emails when i change clients.
this limits my ability to use different machines for development and my

for a long while, i thought i needed better filtering. but i'm really after
something more general than delivering mail into particular folders. it's
really about being able to run rules to associate meta-data with emails.
some of these tags would be a little bit like a gmail labels. others would
be the usual standard headers and so on that come with the emails.

See http://yukatan.sourceforge.net/sql/yukatan.html for the relational
> data model I created.

i'm having problems accessing some of the content but i see the general idea

> 3 any interest in developing these ideas further?
> Yes. I'm not totally happy with GMail, and every now and then I've
> been playing with the idea of porting the relational model to JCR node
> types

great :-)

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?

and the import tools to use the JCR API.

which import tools?

- robert

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message