Re: Repositories refactoring proposal
> > IMHO James needs to have people doing things to it, we've had a > > virtual > > -1 > > I know I'm going to step on toes by saying this but... > > James does not need more code before James needs management > and design. > > Everyone, except for Stefano, seems to be too busy. Which is > understandable, but has consequences. > > James isn't going to attract many new developers with the "Do > what you want, the code is in CVS" > attitude that seems to be the persuasion around here. And > the code looks it too, everyone goes into their corner, does > their own thing, returns and commits. Please look at this page http://james.apache.org/todo.html Most of my commits and most of my proposals are mentioned in the OLD TODO list. I worked mostly on bugfixes and JIRA cleanup and: - I added the "8BITMIME extension", and "enhanced status codes extension (RFC 2034)". - I'm working on "Revisit the MailRepository", "Revisit the SpoolRepository" and "Define a simple mechaism for addressing repositories". - I'm refactoring the Avalon Blocks in order to simplify the removal of the phoenix container (see "Container options"). - I'm partecipating in "Discuss and design the next revision of the Mailet API." - My local james has "Complete support for delivery service notification" but I don't like the way I implemented it so I'll wait to have a refactored James that will allow me to have a more clean approach to this. As you can see everything I'm doing has been written in a page that was last updated on January 2005 :-) I'll take your reply as a feature request for IMAP, but I don't have knowledge and time to work on IMAP, but I'll put my efforts in helping anyone that will provide an alpha working implementation because I think IMAP is a needed feature. Most of the ROADMAP has already been discussed plenty of times, we just need people to do something from the roadmap. You can see that IMAP is in the TODO list. If you want to contribute code or sponsor a developer for that feature you're welcome ;-) Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
On 23/08/05, Kervin L. Pierre <[EMAIL PROTECTED]> wrote: > I know I'm going to step on toes by saying this > but... > > James does not need more code before James needs > management and design. I don't think you are being overly critical, but I do think you are oversimplifying the situation. James has had a stable and consistent design for a few years, it is well understood by the commiters, and the future of James has been discussed over and over. What we have lacked is people with the time to expend on reaching our goals. Stefano is not "doing his own thing" we have elected him to join us because not only does he understand James, he also understands our direction and has demonstrated his ability to adapt his point of view when the group disagrees with him. What I am in favour of is encouraging people to return to the propose, commit, review approach we have traditionally taken. This may result in a longer cycle between stable major versions but it does not diminish quality, what we have to ensure is that the review is conscientious, and that we take the time to reach consensus of approach. > I hope I am not being overly critical. I have > had high expections of James. Especially being > an Apache project and all. In what way does James fail to meet your high expectations? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
Danny Angus wrote: On 8/22/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote: IMHO the ONLY way to move is to CODE something +1 IMHO James needs to have people doing things to it, we've had a virtual -1 I know I'm going to step on toes by saying this but... James does not need more code before James needs management and design. Everyone, except for Stefano, seems to be too busy. Which is understandable, but has consequences. James isn't going to attract many new developers with the "Do what you want, the code is in CVS" attitude that seems to be the persuasion around here. And the code looks it too, everyone goes into their corner, does their own thing, returns and commits. I hope I am not being overly critical. I have had high expections of James. Especially being an Apache project and all. Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
On 8/22/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > IMHO the ONLY way to move is to CODE something +1 IMHO James needs to have people doing things to it, we've had a virtual moratorium on changes this last while and I see our current position as being one in which we can afford to, in fact you might argue that we need to, make rapid evolutionary changes to revitalise both the product and our enthusiasm. The _next_ stage will be to refactor, consolidate, and mature the changes in response to observations, tests and theory (aka, "Boys, ah've bin a figurin and the way I figures it it is this..") Don't forget that we have a competent mature product available for download which has been proven in hundreds (thousands? I don't know!) of commercial deployments, we don't have to rush the next version out to satisfy users *or* shareholders. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limit ed. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
On 8/22/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > IMHO the ONLY way to move is to CODE something +1 -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
7) IMAP: create This sounds like the most appealing :). Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
Danny Angus wrote: > I've been messing with Derby recently and wondered if we shouldn't > just bundle derby I'd favor packages that bundled Derby or Axion so that we had a known database. Since we would have pre-configured and packaged the database, there would not be any installation effort required of the user. However, I'm not entirely prepared to ditch file system support entirely, although, I'm just about in favor of ditching or rewriting the current file system based repositories. Personally, dbfile is my most-used format. Ironically, considering the current negative impression a few seem to have, the database format is by far the more reliable. I'd favor fixing cornerstone as necessary. There are all sorts of issues in the code, including lack of scalability and missing methods. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
>I'm not sure how much appetite we have for adopting things like this, it > may be more advantageous (not to mention pragmatic) for us to either > adopt Paul's changes Actually, if you go back and read the early messages about Paul's picofication work, you will find that we've been waiting for it from the beginning. He was using another Avalon project as his guinea pig this time. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
Serge summed it up perfectly... > And NNTP, if possible (I never use it, but would love to unify things). +1 > I would focus on designing a new API to our specific needs, and provide > migration utilities for existing users. +1 d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
Jason Webb wrote: One repository to rule them all, one repository to find them. One repository to rule them all and in the darkness bind them :) (Apologies to JRR One of my primary design goals is to make sure the user can access their email using POP3 or IMAP4 in whatever way they choose. I will implement the file based repositories to have the required methods for IMAP. This will involve changes to the cornerstone classes. Is the best thing to do with these changes to move them into James proper or to attempt to submit changes to the Cornerstone project? And NNTP, if possible (I never use it, but would love to unify things). I would focus on designing a new API to our specific needs, and provide migration utilities for existing users. Cornerstone was designed for ad-hoc usage, not tailored to our needs, so I would migrate away regardless of its history or current ownership. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
> If your interested in doing much with Cornerstone, I would seriously > suggest someone post a note to Paul since he was the last working on it > and had some plans on resurrecting it. Paul is a contributor here too, so this will pass across his mailbox.. I'm not sure how much appetite we have for adopting things like this, it may be more advantageous (not to mention pragmatic) for us to either adopt Paul's changes (which I suspect will align nicely with our emerging direction) or to make a clean sweep and develop the services targeted at our specific requirements, possibly reducing the bang by evolving them from a cornerstone fork. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
> -Original Message- > From: Soren Hilmer [mailto:[EMAIL PROTECTED] ... > If CornerStone is alive and well, submitting the code back would be a good > move. But If my memory does not fail me completely (I often get the issues > on Phoenix and CornerStone and Avalon mixedup in my head) the current > James 2.1 branch is stuck with an old CornerStone build (actually one that > is not even tagged in the CornerStone-CVS, so we cannot recreate it) in > which case we also need to put the code into James. Cornerstone isn't necessarily "alive and well" but it is accessible. We moved it to Excalibur so that there would at least be somebody watching over it. However, if James would rather take it over, I don't think anyone in Excalibur will complain too much. If your interested in doing much with Cornerstone, I would seriously suggest someone post a note to Paul since he was the last working on it and had some plans on resurrecting it. jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
> The database repositories are simple to deal with as we (James) own the > code. My main issue is with the Cornerstone file: repositories as they are > "owned" by the Avalon project. I would like to make changes to these, but > I need to know if we are still going to be going forward with > Cornerstone/Avalon or whatever. Cornerstone has been moved to Excalibur. SVN is at: http://svn.apache.org/repos/asf/excalibur/trunk/cornerstone/ I'm fairly certain that if James wants either access or even ownership of Cornerstone, something can be worked out. Last I heard, Paul Hammant was working on refactoring the Cornerstone code so it wasn't so coupled to Avalon and couple be used with PicoContainer. jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
Is it not the case that CornerStone is no longer actively maintained (or is it just Avalon) In which case I would prefer moving them into James. If CornerStone is alive and well, submitting the code back would be a good move. But If my memory does not fail me completely (I often get the issues on Phoenix and CornerStone and Avalon mixedup in my head) the current James 2.1 branch is stuck with an old CornerStone build (actually one that is not even tagged in the CornerStone-CVS, so we cannot recreate it) in which case we also need to put the code into James. So the short story IMO is, put it into James and submit it back if it makes sense (the two implementations may of course differ depending on the CornerStone version). --Søren On Wednesday 22 December 2004 15:22, Jason Webb wrote: > > -Original Message- > > From: Soren Hilmer [mailto:[EMAIL PROTECTED] > > Sent: 22 December 2004 14:15 > > To: James Developers List > > Subject: Re: Repositories > > > > On Wednesday 22 December 2004 13:50, Danny Angus wrote: > > > Soren, > > > Derby would be embedded in James, it would not be visible to users at > > > > all, > > > > > and require no additional admin or configuration. > > > The messages would not be visible in the filesystem, but that would be > > > > the > > > > > only drawback. > > > > Okay, sounds a little better. > > > > Still I must say I prefer the file repositories, it is a lot easier to > > support > > a mailserver when you can read the mails currently in process directly > > from > > the filesystem. > > This is AFAIK also the approach serious mailservers like Postfix does > > things. > > > > If we go for an all DB solution. We need better tools to show the > > repositories > > and messages within them. > > > > I can see the problems about destroying/renaming repositories, because > > those > > operations are not supported by CornerStone. > > > > Could it be a compromise that we require DB repositories only when IMAP > > is used, and thereby allowing existing setups to continue with > > file/filedb repositories? > > One repository to rule them all, one repository to find them. One > repository to rule them all and in the darkness bind them :) (Apologies to > JRR > > One of my primary design goals is to make sure the user can access their > email using POP3 or IMAP4 in whatever way they choose. I will implement the > file based repositories to have the required methods for IMAP. This will > involve changes to the cornerstone classes. Is the best thing to do with > these changes to move them into James proper or to attempt to submit > changes to the Cornerstone project? > > > --Søren > > > > > d. > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
I vote for move them into James proper.
You can submit the change to cornerstone too, but lets not loose sight of
the code.
d.
|-+>
| | "Jason Webb" |
| | <[EMAIL PROTECTED]> |
| ||
| | 22/12/2004 02:22 |
| | PM |
| | Please respond to|
| | "James Developers|
| | List"|
| ||
|-+>
>---|
|
|
| To: "'James Developers List'" <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> |
| cc:
|
| Subject: RE: Repositories
|
>---|
> -Original Message-
> From: Soren Hilmer [mailto:[EMAIL PROTECTED]
> Sent: 22 December 2004 14:15
> To: James Developers List
> Subject: Re: Repositories
>
> On Wednesday 22 December 2004 13:50, Danny Angus wrote:
> >
> > Soren,
> > Derby would be embedded in James, it would not be visible to users at
> all,
> > and require no additional admin or configuration.
> > The messages would not be visible in the filesystem, but that would be
> the
> > only drawback.
>
> Okay, sounds a little better.
>
> Still I must say I prefer the file repositories, it is a lot easier to
> support
> a mailserver when you can read the mails currently in process directly
> from
> the filesystem.
> This is AFAIK also the approach serious mailservers like Postfix does
> things.
>
> If we go for an all DB solution. We need better tools to show the
> repositories
> and messages within them.
>
> I can see the problems about destroying/renaming repositories, because
> those
> operations are not supported by CornerStone.
>
> Could it be a compromise that we require DB repositories only when IMAP
is
> used, and thereby allowing existing setups to continue with file/filedb
> repositories?
>
One repository to rule them all, one repository to find them. One
repository
to rule them all and in the darkness bind them :) (Apologies to JRR
One of my primary design goals is to make sure the user can access their
email using POP3 or IMAP4 in whatever way they choose. I will implement the
file based repositories to have the required methods for IMAP. This will
involve changes to the cornerstone classes. Is the best thing to do with
these changes to move them into James proper or to attempt to submit
changes
to the Cornerstone project?
> --Søren
>
> >
> > d.
> >
> >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***
The information in this e-mail is confidential and for use by the addressee(s)
only. If you are not the intended recipient (or responsible for delivery of the
message to the intended recipient) please notify us immediately on 0141 306
2050 and delete the message from your computer. You may not copy or forward it
or use or disclose its contents to any other person. As Internet communications
are capable of data corruption Student Loans Company Limited does not accept
any responsibility for changes made to this message after it was sent. For
this reason it may be inappropriate to rely on advice or opinions contained in
an e-mail without obtaining written confirmation of it. Neither Student Loans
Company Limited or the sender accepts any liability or responsibility for
viruses as it is your responsibility to scan attachments (if any). Opinions and
views expressed in this e-mail are those of the sender and may not reflect the
opinions and views of The Student Loans Company Limited.
This footnote also confirms that this email message has been swept for the
presence of computer viruses.
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
> -Original Message- > From: Soren Hilmer [mailto:[EMAIL PROTECTED] > Sent: 22 December 2004 14:15 > To: James Developers List > Subject: Re: Repositories > > On Wednesday 22 December 2004 13:50, Danny Angus wrote: > > > > Soren, > > Derby would be embedded in James, it would not be visible to users at > all, > > and require no additional admin or configuration. > > The messages would not be visible in the filesystem, but that would be > the > > only drawback. > > Okay, sounds a little better. > > Still I must say I prefer the file repositories, it is a lot easier to > support > a mailserver when you can read the mails currently in process directly > from > the filesystem. > This is AFAIK also the approach serious mailservers like Postfix does > things. > > If we go for an all DB solution. We need better tools to show the > repositories > and messages within them. > > I can see the problems about destroying/renaming repositories, because > those > operations are not supported by CornerStone. > > Could it be a compromise that we require DB repositories only when IMAP is > used, and thereby allowing existing setups to continue with file/filedb > repositories? > One repository to rule them all, one repository to find them. One repository to rule them all and in the darkness bind them :) (Apologies to JRR One of my primary design goals is to make sure the user can access their email using POP3 or IMAP4 in whatever way they choose. I will implement the file based repositories to have the required methods for IMAP. This will involve changes to the cornerstone classes. Is the best thing to do with these changes to move them into James proper or to attempt to submit changes to the Cornerstone project? > --Søren > > > > > d. > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
On Wednesday 22 December 2004 13:50, Danny Angus wrote: > > Soren, > Derby would be embedded in James, it would not be visible to users at all, > and require no additional admin or configuration. > The messages would not be visible in the filesystem, but that would be the > only drawback. Okay, sounds a little better. Still I must say I prefer the file repositories, it is a lot easier to support a mailserver when you can read the mails currently in process directly from the filesystem. This is AFAIK also the approach serious mailservers like Postfix does things. If we go for an all DB solution. We need better tools to show the repositories and messages within them. I can see the problems about destroying/renaming repositories, because those operations are not supported by CornerStone. Could it be a compromise that we require DB repositories only when IMAP is used, and thereby allowing existing setups to continue with file/filedb repositories? --Søren > > d. > > > *** > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient (or responsible > for delivery of the message to the intended recipient) please notify us > immediately on 0141 306 2050 and delete the message from your computer. You > may not copy or forward it or use or disclose its contents to any other > person. As Internet communications are capable of data corruption Student > Loans Company Limited does not accept any responsibility for changes made > to this message after it was sent. For this reason it may be inappropriate > to rely on advice or opinions contained in an e-mail without obtaining > written confirmation of it. Neither Student Loans Company Limited or the > sender accepts any liability or responsibility for viruses as it is your > responsibility to scan attachments (if any). Opinions and views expressed > in this e-mail are those of the sender and may not reflect the opinions and > views of The Student Loans Company Limited. > > This footnote also confirms that this email message has been swept for the > presence of computer viruses. > > ** > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
Jason Webb wrote: I've only played with Cloudscape before (Derby's forerunner if you don't know, I'm sure Danny does!). How would people feel about dropping file: support altogether and only using db: repositories then? However this would mean that dbfile: wouldn't work. I don't want to kill a feature "accidentally" that a lot of people rely on. Good with me, as long as we have migration tools. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
> I feel very badly about doing that, as we suddenly demand installation of a DB > to run James. Soren, Derby would be embedded in James, it would not be visible to users at all, and require no additional admin or configuration. The messages would not be visible in the filesystem, but that would be the only drawback. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
Makes a lot of sense, and although OO purists' hearts my flutter, it is better to move forward with a viable solution. Since file repositories need to be carried forward, my feeling is that it be best to follow the path you have already begun ... -Original Message- From: Jason Webb [mailto:[EMAIL PROTECTED] ... File based repositories do not support 2 key IMAP requirements: They cannot be renamed or destroyed (deleted). To be honest the rest of the issues are just wiring. They're not trivial issues, but not show stoppers. My opinion (currently) is that MailRepository must have two additional methods: .deleteRepository() and .renameRepository(String newname) This mirrors the Java File() class in principal. However some people hav expressed a feeling that this is not very OO, as a factory of some sort should be responsible for this management. The issue I have with this is that the Cornerstone repositories create themselves without the use of a factory but after that have no additional management features other than that you can add and delete items from the repository "bucket". Related to this is that when you delete a user from James their mailbox never gets deleted! Does that make sense? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
> I haven't played with derby/cloudscape, but if it's anything like HSQLDB > (another pure java db), when running in embedded mode, only one app can > connect to the database at a time, which is a real pain in the ass. .. but if you want to access the db you can run it in network mode, sounds like a pain for the lazy more than a real issue. > course, as a default option so that people don't have to set up their own > database server to use the db repositories, it could be nice. I was thinking more of just the default, period. If anyone wants to use files they can choose to. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
> -Original Message- > From: Soren Hilmer [mailto:[EMAIL PROTECTED] > Sent: 22 December 2004 11:17 > To: James Developers List > Subject: Re: Repositories > > I feel very badly about doing that, as we suddenly demand installation of > a DB > to run James. > > I believe this is a major drawback for the installed userbase, much > greater > than a change from Java-1.3 to Java-1.4. > > I must admit that I have not followed the IMAP discussions closely, could > you > perhaps sum up, what the problem with the filebased repositories are in > regard to IMAP? > File based repositories do not support 2 key IMAP requirements: They cannot be renamed or destroyed (deleted). To be honest the rest of the issues are just wiring. They're not trivial issues, but not show stoppers. My opinion (currently) is that MailRepository must have two additional methods: .deleteRepository() and .renameRepository(String newname) This mirrors the Java File() class in principal. However some people hav expressed a feeling that this is not very OO, as a factory of some sort should be responsible for this management. The issue I have with this is that the Cornerstone repositories create themselves without the use of a factory but after that have no additional management features other than that you can add and delete items from the repository "bucket". Related to this is that when you delete a user from James their mailbox never gets deleted! Does that make sense? > --Søren > > > On Wednesday 22 December 2004 11:34, Jason Webb wrote: > > I've only played with Cloudscape before (Derby's forerunner if you don't > > know, I'm sure Danny does!). How would people feel about dropping file: > > support altogether and only using db: repositories then? > > However this would mean that dbfile: wouldn't work. I don't want to kill > a > > feature "accidentally" that a lot of people rely on. > > > > Any thoughts? > > > > -- Jason > > > > > -Original Message- > > > From: Danny Angus [mailto:[EMAIL PROTECTED] > > > Sent: 22 December 2004 10:20 > > > To: James Developers List > > > Subject: Re: Repositories > > > > > > I've been messing with Derby recently and wondered if we shouldn't > > > just bundle derby for people who don't care what happens..? > > > > > > Otherwise I think we will need to deprecate the cornerstone ones in > > > favour of something better for our sanity if nothing else. These have > > > had "issues" for as long as I've been involved and I'd cheer, loudly, > > > if we saw the back of them. I believe that the NNTP server uses a much > > > simpler format for its file repo's, mabey you could re-use something > > > from that? > > > > > > d. > > > > > > On Wed, 22 Dec 2004 09:55:15 -, Jason Webb <[EMAIL PROTECTED]> wrote: > > > > Sorry to all those waiting for the IMAP work to be committed, but > what > > > > > > with > > > > > > > changing jobs and looking after 2 small people my time has become a > > > > > > little > > > > > > > tight... > > > > > > > > However, this has not stopped me thinking about the biggest issue > the > > > > > > IMAP > > > > > > > server faces and that is the repository interface. At the moment I > feel > > > > > > I'm > > > > > > > trying to ram a very square peg into a very round hole and it's > fairly > > > > painful. > > > > > > > > The database repositories are simple to deal with as we (James) own > the > > > > code. My main issue is with the Cornerstone file: repositories as > they > > > > > > are > > > > > > > "owned" by the Avalon project. I would like to make changes to > these, > > > > > > but I > > > > > > > need to know if we are still going to be going forward with > > > > Cornerstone/Avalon or whatever. > > > > > > > > -- Jason > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Søren Hilmer, M.Sc. > R&D manager Phone: +45 72 30 64 00 > TietoEnator IT+ A/S Fax:+45 72 30 64 02 > Ved Lunden 12 Direct: +45 72 30 64 57 > DK-8230 ÅbyhøjEmail: soren.hilmer tietoenator.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
I've only played with Cloudscape before (Derby's forerunner if you don't know, I'm sure Danny does!). How would people feel about dropping file: Dropping files might be accepted, but not DBFiles. Having no "pure file" support, would mean that users would need a better "remote manager", and since there's nothing like this for JAMES with DB at the moment, it would mean the JAMES wouldn't work out of the box. support altogether and only using db: repositories then? However this would mean that dbfile: wouldn't work. I don't want to kill a feature "accidentally" that a lot of people rely on. DBFiles are great, and from our tests, is the best combination possible. These days, mails are big and have attachments too, and we found no DB till yet that would be able to handle this the right way(with the same hardware like the one used for DBFiels). Having the headers only in the DB is: "taking the best of both worlds" :). Just my 2 euro cents :). Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
I feel very badly about doing that, as we suddenly demand installation of a DB to run James. I believe this is a major drawback for the installed userbase, much greater than a change from Java-1.3 to Java-1.4. I must admit that I have not followed the IMAP discussions closely, could you perhaps sum up, what the problem with the filebased repositories are in regard to IMAP? --Søren On Wednesday 22 December 2004 11:34, Jason Webb wrote: > I've only played with Cloudscape before (Derby's forerunner if you don't > know, I'm sure Danny does!). How would people feel about dropping file: > support altogether and only using db: repositories then? > However this would mean that dbfile: wouldn't work. I don't want to kill a > feature "accidentally" that a lot of people rely on. > > Any thoughts? > > -- Jason > > > -Original Message- > > From: Danny Angus [mailto:[EMAIL PROTECTED] > > Sent: 22 December 2004 10:20 > > To: James Developers List > > Subject: Re: Repositories > > > > I've been messing with Derby recently and wondered if we shouldn't > > just bundle derby for people who don't care what happens..? > > > > Otherwise I think we will need to deprecate the cornerstone ones in > > favour of something better for our sanity if nothing else. These have > > had "issues" for as long as I've been involved and I'd cheer, loudly, > > if we saw the back of them. I believe that the NNTP server uses a much > > simpler format for its file repo's, mabey you could re-use something > > from that? > > > > d. > > > > On Wed, 22 Dec 2004 09:55:15 -, Jason Webb <[EMAIL PROTECTED]> wrote: > > > Sorry to all those waiting for the IMAP work to be committed, but what > > > > with > > > > > changing jobs and looking after 2 small people my time has become a > > > > little > > > > > tight... > > > > > > However, this has not stopped me thinking about the biggest issue the > > > > IMAP > > > > > server faces and that is the repository interface. At the moment I feel > > > > I'm > > > > > trying to ram a very square peg into a very round hole and it's fairly > > > painful. > > > > > > The database repositories are simple to deal with as we (James) own the > > > code. My main issue is with the Cornerstone file: repositories as they > > > > are > > > > > "owned" by the Avalon project. I would like to make changes to these, > > > > but I > > > > > need to know if we are still going to be going forward with > > > Cornerstone/Avalon or whatever. > > > > > > -- Jason > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
I've finally got round to joining the dev list! Personally I don't trust databases with things of this nature, and would prefer to stick with using the file system. Just this week there was another 'I need help urgently' message on the user list - James went screwy because of database issues. I do use the database for user management though... so I think the mix should stay! I haven't played with derby/cloudscape, but if it's anything like HSQLDB (another pure java db), when running in embedded mode, only one app can connect to the database at a time, which is a real pain in the ass. Of course, as a default option so that people don't have to set up their own database server to use the db repositories, it could be nice. Daniel. > -Original Message- > From: Jason Webb [mailto:[EMAIL PROTECTED] > Sent: 22 December 2004 10:34 > To: 'James Developers List'; [EMAIL PROTECTED] > Subject: RE: Repositories > > > I've only played with Cloudscape before (Derby's forerunner if you don't > know, I'm sure Danny does!). How would people feel about dropping file: > support altogether and only using db: repositories then? > However this would mean that dbfile: wouldn't work. I don't want to kill a > feature "accidentally" that a lot of people rely on. > > Any thoughts? > > -- Jason > > > -Original Message- > > From: Danny Angus [mailto:[EMAIL PROTECTED] > > Sent: 22 December 2004 10:20 > > To: James Developers List > > Subject: Re: Repositories > > > > I've been messing with Derby recently and wondered if we shouldn't > > just bundle derby for people who don't care what happens..? > > > > Otherwise I think we will need to deprecate the cornerstone ones in > > favour of something better for our sanity if nothing else. These have > > had "issues" for as long as I've been involved and I'd cheer, loudly, > > if we saw the back of them. I believe that the NNTP server uses a much > > simpler format for its file repo's, mabey you could re-use something > > from that? > > > > d. > > > > > > On Wed, 22 Dec 2004 09:55:15 -, Jason Webb <[EMAIL PROTECTED]> wrote: > > > Sorry to all those waiting for the IMAP work to be committed, but what > > with > > > changing jobs and looking after 2 small people my time has become a > > little > > > tight... > > > > > > However, this has not stopped me thinking about the biggest issue the > > IMAP > > > server faces and that is the repository interface. At the > moment I feel > > I'm > > > trying to ram a very square peg into a very round hole and it's fairly > > > painful. > > > > > > The database repositories are simple to deal with as we > (James) own the > > > code. My main issue is with the Cornerstone file: repositories as they > > are > > > "owned" by the Avalon project. I would like to make changes to these, > > but I > > > need to know if we are still going to be going forward with > > > Cornerstone/Avalon or whatever. > > > > > > -- Jason > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Repositories
I've only played with Cloudscape before (Derby's forerunner if you don't know, I'm sure Danny does!). How would people feel about dropping file: support altogether and only using db: repositories then? However this would mean that dbfile: wouldn't work. I don't want to kill a feature "accidentally" that a lot of people rely on. Any thoughts? -- Jason > -Original Message- > From: Danny Angus [mailto:[EMAIL PROTECTED] > Sent: 22 December 2004 10:20 > To: James Developers List > Subject: Re: Repositories > > I've been messing with Derby recently and wondered if we shouldn't > just bundle derby for people who don't care what happens..? > > Otherwise I think we will need to deprecate the cornerstone ones in > favour of something better for our sanity if nothing else. These have > had "issues" for as long as I've been involved and I'd cheer, loudly, > if we saw the back of them. I believe that the NNTP server uses a much > simpler format for its file repo's, mabey you could re-use something > from that? > > d. > > > On Wed, 22 Dec 2004 09:55:15 -, Jason Webb <[EMAIL PROTECTED]> wrote: > > Sorry to all those waiting for the IMAP work to be committed, but what > with > > changing jobs and looking after 2 small people my time has become a > little > > tight... > > > > However, this has not stopped me thinking about the biggest issue the > IMAP > > server faces and that is the repository interface. At the moment I feel > I'm > > trying to ram a very square peg into a very round hole and it's fairly > > painful. > > > > The database repositories are simple to deal with as we (James) own the > > code. My main issue is with the Cornerstone file: repositories as they > are > > "owned" by the Avalon project. I would like to make changes to these, > but I > > need to know if we are still going to be going forward with > > Cornerstone/Avalon or whatever. > > > > -- Jason > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
I've been messing with Derby recently and wondered if we shouldn't just bundle derby for people who don't care what happens..? Otherwise I think we will need to deprecate the cornerstone ones in favour of something better for our sanity if nothing else. These have had "issues" for as long as I've been involved and I'd cheer, loudly, if we saw the back of them. I believe that the NNTP server uses a much simpler format for its file repo's, mabey you could re-use something from that? d. On Wed, 22 Dec 2004 09:55:15 -, Jason Webb <[EMAIL PROTECTED]> wrote: > Sorry to all those waiting for the IMAP work to be committed, but what with > changing jobs and looking after 2 small people my time has become a little > tight... > > However, this has not stopped me thinking about the biggest issue the IMAP > server faces and that is the repository interface. At the moment I feel I'm > trying to ram a very square peg into a very round hole and it's fairly > painful. > > The database repositories are simple to deal with as we (James) own the > code. My main issue is with the Cornerstone file: repositories as they are > "owned" by the Avalon project. I would like to make changes to these, but I > need to know if we are still going to be going forward with > Cornerstone/Avalon or whatever. > > -- Jason > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
