JSR 170 (Java Content Repository)

[mikezzz]

http://www.artima.com/lejava/articles/contentrepository.html

JSR 170 is a recently verified standard for Java Content Repositories. Looking at the specification, the hierachical model is one that seems to match well with the concept of Folders->Messages->Body->Body Parts structure that JBoss mail uses. Would it be stupid to suggest that we partially implement (via hibernate) this spec and use this structure for managing the persistent data within JBoss Mail.

Some of the pros:

- Natural match with our problem domain (hierachical data structure).
- Static Database schema. Once the JCR implementation stablises the database schema is much less likely to change (no new columns when an class definition changes).
- Versioning could be used to handle messages arriving while a folder's messages are being read.
- Security can be encapsulated within the JCR.

Some cons:

- There are a couple of areas where the API doesn't quite to enough, one example is the Value class does not have a getSize() method (very important for large objects - mail bodies).
- Would more tightly integrate the folder & store implemenations - is this a bad thing??

With regards to planning, I would say this should occur along with the IMAP implemenation as the Folder implemenation will need to change when we introduce IMAP anyway. Initially we would not imlpement the whole spec, only enough to get what we need.

I am interesting in hearing other peoples take on this idea.

[acoliver]

I'll read it but my knee jerk reactions is:

So use what makes sense but don't worry about spec compliance and stuff. I want to do things that get us working. I suggest pulling ideas that you like. I care way more about multi-database support than "standards support" for the back end. Mail admins could give a crap less if we used JSR-170 and more about "can I get the damn thing installed on Oracle in 15 minutes or less".

-Andy

[mikezzz]

Actually now that I have thought about the idea a little more, I am less keen on it. My problem with it will be performance. E.g. the pop LIST command currently (using the hibernate implemenation that I will commit tonight) can return all of the necessary information with a single query, with no joins, filtered only by a single foreign key (very quick). The schema needed to support JSR-170 will mean that more than a single row for each entry in the LIST result set, meaning joins and probably a fair bit of trickery to avoid the n+1 queries thing. We can get better performance & scalability with a schema explictly modeled for our objects and still have a clean design.

Mike.