cvs site unavailable
Key: JAMES-341
URL: http://nagoya.apache.org/jira/browse/JAMES-341
Project: James
Type: Bug
Environment: any
Reporter: Ralf Hauser
on http://jakarta.apache.org/site/cvsindex.html, there are two james entries:
- james-s
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 re
>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
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.
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 i
> 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
> -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 c
> 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
> Corner
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
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]> |
| |
> -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 visi
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, so
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
fea
> 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
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 [mai
> 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
li
> -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 dr
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 t
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
perha
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
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
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
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 momen
23 matches
Mail list logo