You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2007/05/02 11:23:08 UTC
Jukka Zitting Committer Karma
Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
work on a Proof of Concept related to the use of JCR as our unified data
store. The proof of concept will start by focusing on the modelling of the
data in JCR, and will build from the JCR side out, not start with existing
JAMES code at all.
The work should be done in our SVN, hence the need for karma.
+1 from me.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Søren Hilmer <sh...@widetrail.dk>.
+1
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
On Wed, May 2, 2007 11:23, Noel J. Bergman wrote:
> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
> work on a Proof of Concept related to the use of JCR as our unified data
> store. The proof of concept will start by focusing on the modelling of
> the
> data in JCR, and will build from the JCR side out, not start with existing
> JAMES code at all.
>
> The work should be done in our SVN, hence the need for karma.
>
> +1 from me.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
+1
Vincenzo
Noel J. Bergman wrote:
> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
> work on a Proof of Concept related to the use of JCR as our unified data
> store. The proof of concept will start by focusing on the modelling of the
> data in JCR, and will build from the JCR side out, not start with existing
> JAMES code at all.
>
> The work should be done in our SVN, hence the need for karma.
>
> +1 from me.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
> work on a Proof of Concept related to the use of JCR as our unified data
> store. The proof of concept will start by focusing on the modelling of the
> data in JCR, and will build from the JCR side out, not start with existing
> JAMES code at all.
>
> The work should be done in our SVN, hence the need for karma.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> And maybe we are missing svn notifications for the /james/sandbox
> folder: Noel, can you fix it so the next time we don't miss a commit?
I was wrong! The notification message was in the moderation queue: I
just "allowed" jukka at apache to send messages to server-dev ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Danny Angus <da...@apache.org>.
On 5/4/07, Jukka Zitting <ju...@gmail.com> wrote:
> I moved the component now (revision 535391) to server/sandbox.
... and now we have you on the hook! ;-) Welcome!
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Stefano Bagnara <ap...@bago.org>.
Jukka Zitting ha scritto:
> On 5/4/07, Stefano Bagnara <ap...@bago.org> wrote:
>> *My* *preference* is still to have it in "server/sandbox" as this JCR
>> stuff is related to JAMES Server as I don't think we're going to make
>> another JAMES subproject (at the same level of postage, mailet api,
>> jspf, mime4j, jsieve, server) for the JCR backend.
>
> I moved the component now (revision 535391) to server/sandbox.
>
> BR,
>
> Jukka Zitting
Thank you very much :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/4/07, Stefano Bagnara <ap...@bago.org> wrote:
> Noel J. Bergman ha scritto:
> > Stefano Bagnara wrote:
> >> Jukka Zitting ha scritto:
> >>> The prototype JCR store mailet we did during the ApacheCon is now in
> >>> james/sandbox/james-jcr (see revision 535260). It's very simple for
> >>> now, but I'll be working on the prototype during the next few weeks.
> >
> >> Maybe "/james/server/sandbox/" was better that "/james/sandbox/" as it
> >> is specific to the Server product: can we move it?
> [...]
> *My* *preference* is still to have it in "server/sandbox" as this JCR
> stuff is related to JAMES Server as I don't think we're going to make
> another JAMES subproject (at the same level of postage, mailet api,
> jspf, mime4j, jsieve, server) for the JCR backend.
I moved the component now (revision 535391) to server/sandbox.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Michael Wechner <mi...@wyona.com>.
Jukka Zitting wrote:
> Hi,
>
> On 5/5/07, Stefano Bagnara <ap...@bago.org> wrote:
>
>> My concerns where specific to a "product based on JCR, hosted
>> on JAMES project, not related to JAMES Server".
>
>
> Note that the use case I described (email archival) was an answer to
> your question about a potential standalone need for similar tools that
> we're going to write for James in the james-jcr sandbox. I'm not
> proposing that we actually implement such an application *within*
> James, but an external project might well be interested in reusing the
> content model and generic import and access tools that we'll implement
> for James.
I think it would be great from a Content Management POV to have this
working.
It would allow a CMS supporting JCR basically acting as an E-Mail server
and hence reuse/aggregate the emails with other content, e.g. attached
to projects or invoices or whatever.
Big +1 for such an endeavour
Cheers
Michi
>
> Basically the question of whether the code should be in
> james/server/sandbox or james/sandbox. For now I'm most interested in
> targeting just the James server, but if the result is successful I'm
> quite sure that there will be people who'd like to use the same
> content model and supporting code also for other email environments.
>
> Perhaps the optimal solution would be to have one generic component
> that depends only on things like mime4j or javamail and the JCR API
> and another component that contains the James-specific mailet and
> other bindings. But I guess it's easiest to start with just a single
> sandbox component for now and separate things when the code matures.
>
>> Even after reading your message I don't fully understand what you are
>> trying to describe.
>>
>> Is it a JCR client (GUI) specific to Email? Is it a library?
>>
>> Let's call it MCR (mail content repository): how would you describe this
>> "MCR" ? A library that allow you to do THIS, a server product exposing
>> this N services over XXX protocol. Is it instead a library that wrap JCR
>> to make it more "email" oriented?
>
>
> The email archival use case I described would store all email in a
> content repositor using the generic tools and content model from the
> james-jcr component that we're about to implement. On top of that an
> archive application would typically provide a (web) user interface for
> querying the email archives for various purposes, most notably to find
> all correspondence that's relevant to a given audit or lawsuit.
>
> The part that we'd implement in James is just the email to JCR mapping
> that we'll need in any case for using a JCR store within the James
> server.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/5/07, Stefano Bagnara <ap...@bago.org> wrote:
> Let's make it work as a JAMES Server component, THEN, if we'll have
> created something working also standalone we'll discuss and vote for a
> specific sub-product/sub-project.
Sounds good to me!
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Stefano Bagnara <ap...@bago.org>.
Jukka Zitting ha scritto:
> Note that the use case I described (email archival) was an answer to
> your question about a potential standalone need for similar tools that
> we're going to write for James in the james-jcr sandbox.
"email archival" sounded too generic to me: our jdbc and mime-file based
email repositories are already used as "email archival" by someone but
they never deserved a standalone product.
>> Let's call it MCR (mail content repository): how would you describe this
>> "MCR" ? A library that allow you to do THIS, a server product exposing
>> this N services over XXX protocol. Is it instead a library that wrap JCR
>> to make it more "email" oriented?
>
> The email archival use case I described would store all email in a
> content repositor using the generic tools and content model from the
> james-jcr component that we're about to implement. On top of that an
> archive application would typically provide a (web) user interface for
> querying the email archives for various purposes, most notably to find
> all correspondence that's relevant to a given audit or lawsuit.
>
> The part that we'd implement in James is just the email to JCR mapping
> that we'll need in any case for using a JCR store within the James
> server.
This answer perfectly satisfies my need :-)
Let's make it work as a JAMES Server component, THEN, if we'll have
created something working also standalone we'll discuss and vote for a
specific sub-product/sub-project.
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/5/07, Stefano Bagnara <ap...@bago.org> wrote:
> My concerns where specific to a "product based on JCR, hosted
> on JAMES project, not related to JAMES Server".
Note that the use case I described (email archival) was an answer to
your question about a potential standalone need for similar tools that
we're going to write for James in the james-jcr sandbox. I'm not
proposing that we actually implement such an application *within*
James, but an external project might well be interested in reusing the
content model and generic import and access tools that we'll implement
for James.
Basically the question of whether the code should be in
james/server/sandbox or james/sandbox. For now I'm most interested in
targeting just the James server, but if the result is successful I'm
quite sure that there will be people who'd like to use the same
content model and supporting code also for other email environments.
Perhaps the optimal solution would be to have one generic component
that depends only on things like mime4j or javamail and the JCR API
and another component that contains the James-specific mailet and
other bindings. But I guess it's easiest to start with just a single
sandbox component for now and separate things when the code matures.
> Even after reading your message I don't fully understand what you are
> trying to describe.
>
> Is it a JCR client (GUI) specific to Email? Is it a library?
>
> Let's call it MCR (mail content repository): how would you describe this
> "MCR" ? A library that allow you to do THIS, a server product exposing
> this N services over XXX protocol. Is it instead a library that wrap JCR
> to make it more "email" oriented?
The email archival use case I described would store all email in a
content repositor using the generic tools and content model from the
james-jcr component that we're about to implement. On top of that an
archive application would typically provide a (web) user interface for
querying the email archives for various purposes, most notably to find
all correspondence that's relevant to a given audit or lawsuit.
The part that we'd implement in James is just the email to JCR mapping
that we'll need in any case for using a JCR store within the James
server.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Stefano Bagnara <ap...@bago.org>.
Jukka Zitting ha scritto:
> Hi,
>
> On 5/5/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Can you make a rationale about a standalone product regarding JCR and
>> Mail but not involving JAMES Server ?
>> What exactly should such a component to?
>
> There's a *strong* need in many organizations to archive *all* their
> email in an easily searchable and integrateable repository. Currently
> many of the major content repository vendors are getting a large part
> of their revenue from selling such email archives.
>
> Such an archive is typically added as an extra component that is just
> fed by whatever email server the organization is using. Typically the
> email server just has a catchall forwarder that copies all in- and
> outgoing messages to such an archive.
Hi Jukka,
first of all I want to make clear that I don't have anything against JCR
and that I think it will be really useful inside JAMES Server. My
concerns where specific to a "product based on JCR, hosted on JAMES
project, not related to JAMES Server".
Even after reading your message I don't fully understand what you are
trying to describe.
Is it a JCR client (GUI) specific to Email? Is it a library?
Let's call it MCR (mail content repository): how would you describe this
"MCR" ? A library that allow you to do THIS, a server product exposing
this N services over XXX protocol. Is it instead a library that wrap JCR
to make it more "email" oriented?
I'm just trying to understand a vision (your vision) that I'm missing.
At the moment it still looks like something very specific to our mail
server: we could use JCR as the storage api for JAMES Server, and this
would let users to use other JCR tools to access the same content.
Stefano
PS: I'm not trying to criticize anything, I'm really interested
understanding the vision.
PS2: I'm almost sure that a JCR based backend will be a good thing to
JAMES. MY only doubt is about to make it THE api to our backend or
simply a possible implementation of our backend (and this depends mainly
on the POC results)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/5/07, Ahmed Mohombe <am...@yahoo.com> wrote:
> I don't expect you to agree :), but if you would feed a JCR based DMS with
> a few GB of documents I'm convinced you would see what I mean :).
We have production systems with millions of documents and terabytes of
data in a JCR content repository, so as you expected I don't agree
with you. :-) Of course the scalability and performance is conditional
to how well your content model and use cases match the characteristics
that the repository is designed and optimized for.
Email storage is different from the scenarios I've so far seen
Jackrabbit being used in, so at this point I can't guarantee that we
won't face performance issues, but as of now I don't see bottlenecks
that we couldn't at least work around.
> > One important aspect in achieving good performance is how you model
> > your content.
> In most cases this is not really an option for the developers, as the required
> "metadata" from documents is already to a high degree predefined by the customer.
Well, there's typically some flexibility between the high-level
requirements and how you reflect that in your implementation.
Otherwise you wouldn't have any need for the DB specialists you
mentioned. :-)
> This is not a bash against JCR, but just a few cents from my experience.
> In a lot of projects, JCR got a fair chance, but failed, mostly for performance
> reasons (the developers loved the API). After several optimization trials, the
> cheapest solution was always to get a few very expensive DB specialists
> and have the problem solved the "relational way" :).
I'd love to discuss the problems you faced, but perhaps the specifics
are better suited for the Jackrabbit mailing lists.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Ahmed Mohombe <am...@yahoo.com>.
>> The problem I see however is that most big DMSes *don't* use JCR
>> because it's slow when it comes to such big amount of documents
>> (it's nice nice in theory but not in practice).
>
> I'm not sure I understand your point. Just like with JDBC, performance
> is mostly a question of the implementation not the API. There aren't
> any inherent performance or scalability bottlenecks in the JCR API, so
> perhaps you are referring to the Jackrabbit implementation?
The API/Specification is just the theory, not what really powers an application.
Of course it's the implementation. Unfortunately not just jackrabbit but all
available JCR solutions so far are slow from this perspective. This is of course not the fault
of the API/Specification (only if requires things that can't have fast implementation :) ).
>> My experience is that if a (JCR) solution for mail archive wants to be
>> usable
>> to the potential users (much more than is JCR to CMSes and DMSes)
>> performance should be the first and most important feature.
>
> I don't quite agree that performance is the "first and most important"
> feature, but it certainly
> is an important aspect. While there are many things to be done for
> better Jackrabbit performance (and we're working on that), I already
> find Jackrabbit quite fast for many typical operations.
I don't expect you to agree :), but if you would feed a JCR based DMS with a few
GB of documents I'm convinced you would see what I mean :).
> One important aspect in achieving good performance is how you model
> your content.
In most cases this is not really an option for the developers, as the required "metadata" from
documents is already to a high degree predefined by the customer.
This is not a bash against JCR, but just a few cents from my experience.
In a lot of projects, JCR got a fair chance, but failed, mostly for performance reasons (the
developers loved the API).
After several optimization trials, the cheapest solution was always to get a few very expensive DB
specialists and have the problem solved the "relational way" :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/5/07, Ahmed Mohombe <am...@yahoo.com> wrote:
> The problem I see however is that most big DMSes *don't* use JCR
> because it's slow when it comes to such big amount of documents
> (it's nice nice in theory but not in practice).
I'm not sure I understand your point. Just like with JDBC, performance
is mostly a question of the implementation not the API. There aren't
any inherent performance or scalability bottlenecks in the JCR API, so
perhaps you are referring to the Jackrabbit implementation?
> My experience is that if a (JCR) solution for mail archive wants to be usable
> to the potential users (much more than is JCR to CMSes and DMSes)
> performance should be the first and most important feature.
I don't quite agree that performance is the "first and most important"
feature, but it certainly
is an important aspect. While there are many things to be done for
better Jackrabbit performance (and we're working on that), I already
find Jackrabbit quite fast for many typical operations.
One important aspect in achieving good performance is how you model
your content. The JCR model allows a couple of nice modelling options
not available in relational databases, most notably in JCR it is
possible to avoid many cases of relational joins. For example JCR
allows you to store a parsed list of message recipients as a
multivalued property of a message node, whereas the equivalent
relational model would require a separate table. I would in fact argue
that a JCR solution could easily achieve stellar performance for use
cases like "find all messages that contain these keywords and that
were sent to or from this domain within this timeframe".
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Ahmed Mohombe <am...@yahoo.com>.
>> Can you make a rationale about a standalone product regarding JCR and
>> Mail but not involving JAMES Server ?
>> What exactly should such a component to?
>
> There's a *strong* need in many organizations to archive *all* their
> email in an easily searchable and integrateable repository. Currently
> many of the major content repository vendors are getting a large part
> of their revenue from selling such email archives.
>
> Such an archive is typically added as an extra component that is just
> fed by whatever email server the organization is using. Typically the
> email server just has a catchall forwarder that copies all in- and
> outgoing messages to such an archive.
Indeed. Mail handling as "documents" is a very important requirement in most (big) DMSes(Document
Management Systems) these days, and it's also not easy to implement.
The problem I see however is that most big DMSes *don't* use JCR because it's slow when it comes to
such big amount of documents (it's nice nice in theory but not in practice).
My experience is that if a (JCR) solution for mail archive wants to be usable to the potential users
(much more than is JCR to CMSes and DMSes) performance should be the first and most important feature.
just my 2 cents,
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/5/07, Stefano Bagnara <ap...@bago.org> wrote:
> Can you make a rationale about a standalone product regarding JCR and
> Mail but not involving JAMES Server ?
> What exactly should such a component to?
There's a *strong* need in many organizations to archive *all* their
email in an easily searchable and integrateable repository. Currently
many of the major content repository vendors are getting a large part
of their revenue from selling such email archives.
Such an archive is typically added as an extra component that is just
fed by whatever email server the organization is using. Typically the
email server just has a catchall forwarder that copies all in- and
outgoing messages to such an archive.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JCR back-end
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
>>> I (or Jukka or I, depending on whom gets to what, when) are going to
>>> rip out the JCR parts into standalone classes, and then have some
>>> driver code for reading a message into the JCR, recreating the
>>> message from the JCR, etc. Once that's all done, we'll start moving
>>> it into JAMES, but we'll also want to preserve the ability for
>
>> I don't think we're going to make another JAMES subproject [for]
>> the JCR backend.
>
> <<shrug>> We might end up with just that. Apparently, there is a lot of interest in storing e-mail in a JCR, and we are just (one of) the first to give it a serious go in Open Source. For now, I'd prefer to work on it and see what firms up.
>
> --- Noel
Can you make a rationale about a standalone product regarding JCR and
Mail but not involving JAMES Server ?
What exactly should such a component to?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
JCR back-end
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I (or Jukka or I, depending on whom gets to what, when) are going to
> > rip out the JCR parts into standalone classes, and then have some
> > driver code for reading a message into the JCR, recreating the
> > message from the JCR, etc. Once that's all done, we'll start moving
> > it into JAMES, but we'll also want to preserve the ability for
> I don't think we're going to make another JAMES subproject [for]
> the JCR backend.
<<shrug>> We might end up with just that. Apparently, there is a lot of interest in storing e-mail in a JCR, and we are just (one of) the first to give it a serious go in Open Source. For now, I'd prefer to work on it and see what firms up.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Stefano Bagnara wrote:
>
>> Jukka Zitting ha scritto:
>>> The prototype JCR store mailet we did during the ApacheCon is now in
>>> james/sandbox/james-jcr (see revision 535260). It's very simple for
>>> now, but I'll be working on the prototype during the next few weeks.
>
>> Maybe "/james/server/sandbox/" was better that "/james/sandbox/" as it
>> is specific to the Server product: can we move it?
>
> I can, but although it currently has a mailet in it, I (or Jukka or I, depending on whom gets to what, when) are going to rip out the JCR parts into standalone classes, and then have some driver code for reading a message into the JCR, recreating the message from the JCR, etc. Once that's all done, we'll start moving it into JAMES, but we'll also want to preserve the ability for standalone code.
>
> So I don't recall care about where it is too much now.
Well, we have a STATUS file that should be moved back to server trunk
(after Robert refactored into modules it has been misplaced):
http://svn.apache.org/repos/asf/james/server/trunk/phoenix-deployment/STATUS
It should be updated to reference the jcr sandbox goal, status, owner
(weird word, but let's say it is the list of the most active committers
for that sandbox).
*My* *preference* is still to have it in "server/sandbox" as this JCR
stuff is related to JAMES Server as I don't think we're going to make
another JAMES subproject (at the same level of postage, mailet api,
jspf, mime4j, jsieve, server) for the JCR backend.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Jukka Zitting Committer Karma
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Jukka Zitting ha scritto:
> > The prototype JCR store mailet we did during the ApacheCon is now in
> > james/sandbox/james-jcr (see revision 535260). It's very simple for
> > now, but I'll be working on the prototype during the next few weeks.
> Maybe "/james/server/sandbox/" was better that "/james/sandbox/" as it
> is specific to the Server product: can we move it?
I can, but although it currently has a mailet in it, I (or Jukka or I, depending on whom gets to what, when) are going to rip out the JCR parts into standalone classes, and then have some driver code for reading a message into the JCR, recreating the message from the JCR, etc. Once that's all done, we'll start moving it into JAMES, but we'll also want to preserve the ability for standalone code.
So I don't recall care about where it is too much now.
> And maybe we are missing svn notifications for the /james/sandbox
> folder: Noel, can you fix it so the next time we don't miss a commit?
:-) As you later noticed, we're already fine. It was just pending moderation.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Stefano Bagnara <ap...@bago.org>.
Jukka Zitting ha scritto:
> The prototype JCR store mailet we did during the ApacheCon is now in
> james/sandbox/james-jcr (see revision 535260). It's very simple for
> now, but I'll be working on the prototype during the next few weeks.
>
> BR,
>
> Jukka Zitting
Cool! I will look at it for sure!
Maybe "/james/server/sandbox/" was better that "/james/sandbox/" as it
is specific to the Server product: can we move it?
And maybe we are missing svn notifications for the /james/sandbox
folder: Noel, can you fix it so the next time we don't miss a commit?
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/4/07, Serge Knystautas <sk...@gmail.com> wrote:
> On 5/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> > Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
> > work on a Proof of Concept related to the use of JCR as our unified data
> > store. The proof of concept will start by focusing on the modelling of the
> > data in JCR, and will build from the JCR side out, not start with existing
> > JAMES code at all.
>
> Commit privs granted to Jukka.
Thanks!
The prototype JCR store mailet we did during the ApacheCon is now in
james/sandbox/james-jcr (see revision 535260). It's very simple for
now, but I'll be working on the prototype during the next few weeks.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Serge Knystautas <sk...@gmail.com>.
On 5/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
> work on a Proof of Concept related to the use of JCR as our unified data
> store. The proof of concept will start by focusing on the modelling of the
> data in JCR, and will build from the JCR side out, not start with existing
> JAMES code at all.
Commit privs granted to Jukka.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Danny Angus <da...@apache.org>.
+1
On 5/2/07, Norman Maurer <no...@apache.org> wrote:
> Stefano Bagnara schrieb:
> > Noel J. Bergman ha scritto:
> >
> >> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
> >> work on a Proof of Concept related to the use of JCR as our unified data
> >> store. The proof of concept will start by focusing on the modelling of the
> >> data in JCR, and will build from the JCR side out, not start with existing
> >> JAMES code at all.
> >>
> >> The work should be done in our SVN, hence the need for karma.
> >>
> >> +1 from me.
> >>
> >> --- Noel
> >>
> >
> > +1
> >
> > Stefano
> >
> > PS: why don't we let every ASF committer to have write-rights in our
> > sandbox folder? This is similar to what Maven project did.
> >
> >
> >
>
> +1
> Norman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Norman Maurer <no...@apache.org>.
Stefano Bagnara schrieb:
> Noel J. Bergman ha scritto:
>
>> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
>> work on a Proof of Concept related to the use of JCR as our unified data
>> store. The proof of concept will start by focusing on the modelling of the
>> data in JCR, and will build from the JCR side out, not start with existing
>> JAMES code at all.
>>
>> The work should be done in our SVN, hence the need for karma.
>>
>> +1 from me.
>>
>> --- Noel
>>
>
> +1
>
> Stefano
>
> PS: why don't we let every ASF committer to have write-rights in our
> sandbox folder? This is similar to what Maven project did.
>
>
>
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Jukka Zitting Committer Karma
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Jukka Zitting, JackRabbit Committer & PMC Chair, has volunteered to help
> work on a Proof of Concept related to the use of JCR as our unified data
> store. The proof of concept will start by focusing on the modelling of the
> data in JCR, and will build from the JCR side out, not start with existing
> JAMES code at all.
>
> The work should be done in our SVN, hence the need for karma.
>
> +1 from me.
>
> --- Noel
+1
Stefano
PS: why don't we let every ASF committer to have write-rights in our
sandbox folder? This is similar to what Maven project did.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Jukka Zitting Committer Karma
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Sorry for posting this to dev@ instead of the PMC list. And I should have
> also noted it as a vote (although the Karma reference probably made it
> clear).
>
> --- Noel
Don't worry. I have no problems with public votes, and you already
collected 4 +1, so, even without the "[VOTE]" prefix you had more
consensus than most previous votes ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE] Jukka Zitting Committer Karma
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sorry for posting this to dev@ instead of the PMC list. And I should have
also noted it as a vote (although the Karma reference probably made it
clear).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org