What the EU OSS migration guidelines say about JAMES
Todays news had reference to a study of the european community about their view of OSS deployment and migration. The document is availbale at http://www.europa.eu.int/ISPO/ida/jsps/index.jsp?fuseAction=showDocumentparent=newsdocumentID=1647. Also JAMES was mentioned as possible MTA, beside the major ones like sendmail, exim aso. Here's what they wrote on page 38: Another interesting product is the Apache James mail server. This is intended to be a fully fledged MTA written in Java. It lacks some features at the moment but is worth keeping an eye on for the future. M
What the EU OSS migration guidelines say about JAMES
Holy F*** thats nice attention ... I wonder what they think it lacks? reading it, it looks like the author wants IMAP. __ Todays news had reference to a study of the european community about their view of OSS deployment and migration. The document is availbale at http://www.europa.eu.int/ISPO/ida/jsps/index.jsp?fuseAction=showDocumentparent=newsdocumentID=1647. Also JAMES was mentioned as possible MTA, beside the major ones like sendmail, exim aso. Here's what they wrote on page 38: Another interesting product is the Apache James mail server. This is intended to be a fully fledged MTA written in Java. It lacks some features at the moment but is worth keeping an eye on for the future. M *** 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: What the EU OSS migration guidelines say about JAMES
Id say, just ask them:-) M - Original Message - From: Danny Angus [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Friday, October 24, 2003 12:14 PM Subject: What the EU OSS migration guidelines say about JAMES Holy F*** thats nice attention ... I wonder what they think it lacks? reading it, it looks like the author wants IMAP. __ Todays news had reference to a study of the european community about their view of OSS deployment and migration. The document is availbale at http://www.europa.eu.int/ISPO/ida/jsps/index.jsp?fuseAction=showDocumentpar ent=newsdocumentID=1647. Also JAMES was mentioned as possible MTA, beside the major ones like sendmail, exim aso. Here's what they wrote on page 38: Another interesting product is the Apache James mail server. This is intended to be a fully fledged MTA written in Java. It lacks some features at the moment but is worth keeping an eye on for the future. M *** 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What the EU OSS migration guidelines say about JAMES
Danny Angus wrote: Holy F*** thats nice attention ... I wonder what they think it lacks? reading it, it looks like the author wants IMAP. This is what I think james lacks: 1) solid fully functional IMAP 2) server side filtering (procmail/sieve like) 3) native OS integration stuff (to avoid running it as root) of course, #2 will need the ability to call external processes via stdin/stdout (so that stuff like spam filtering or virus checking still works). Without those things, it just looks as a proof of concept. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Danny Angus wrote: Kenny, This pattern looks like the one currently used by the mail moderators for apache lists, and as such it's familiarity is probably a benefit. Exactly. I would exactly mimic the behavior that moderators are used to. While James is easily capable of supporting much richer functionality, the problem occurs when you try to figure out how you can use the extremely minimal information that is guaranteed to be passed back in the headers of a reply. TBH disentangling conflicting approve/reject messages is always going to require a people-centric solution as it is a symptom of a people problem (conflicting opinions in the team). As with revision control the software can only go so far and it needs to be supported by having a communicative team with agreed and shared goals. very well said. The workflow system should *NOT* turn into a communication media (like some people do over issue tracking software, for example), but as a more efficient (think asynchronous) way to do approuvals. So, instead of having to log into a web site, see the list of changes and approuve each one of them, you just have to go thru your email and decide to reply or not. One useful addition might be to accept the first command and reject all subsequent ones with a message to the effect that the change has already been approved/rejected, it would then fall to the commiters to discuss and resolve the conflict through a more collaborative channel. Seems like a good idea to me. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What the EU OSS migration guidelines say about JAMES
Please do not forget that we need some easy-to-use, GUI-based as well as command line based administration tools. The present Remote Manager telnet thing is archaic, unsecure, and next to impossible to use if you have more than just a handful of users to administer. Also, we need a GUI-based tool to handle config.xml in an intuitive and yet structured way. ../jaj Stefano Mazzocchi wrote: Danny Angus wrote: Holy F*** thats nice attention ... I wonder what they think it lacks? reading it, it looks like the author wants IMAP. This is what I think james lacks: 1) solid fully functional IMAP 2) server side filtering (procmail/sieve like) 3) native OS integration stuff (to avoid running it as root) of course, #2 will need the ability to call external processes via stdin/stdout (so that stuff like spam filtering or virus checking still works). Without those things, it just looks as a proof of concept. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File_Persistent_Stream_Repository question
Yep, I totally agree. M - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Friday, October 24, 2003 9:00 PM Subject: RE: File_Persistent_Stream_Repository question Mark, I believe that you are correct, although it is probably harmless in the code as it would be a re-entrance issue, and we don't permit that for mail messages. The only changes should be the two you specifically noted. The reason that they would not apply to the Object Repository is that the latter gives you an Object, the other gives you a Stream to process. --- Noel - 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: [PATCH] RemoteDelivery support for multiple delayTimes
Søren, We might do some further tweaking, but I think you've got the right idea. The thought I have is that (down the road) some code might want to accept messages based upon other criteria, so we might want to enlarge upon our options there, possibly by using introspection. A few minor items: (1) Could you submit against branch_2_1_fcs? (2) The spool is purely internal. Let's chance accept() to return the message. (3) Please see GenericRegexMatcher.java for correct usage of the regex code in a multithreaded environment. We need to compile as READ-ONLY, and create a matcher in the executing thread. I'd like to get this change included in our next release. The spooler has never been exposed to anyone, and there are only two calls in the codebase. The James code didn't follow the correct usage pattern for regex previously, but it is documented by the regex classes, as I discovered when trying to do some other things with them. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: fetchmail broken out of the box (was: Re: Missing Blocks are Fatal)
I cd'd to dist/james-2.2.0a15 and typed: bin/run.sh and it failed with the following error: Caused by: java.io.FileNotFoundException: ../apps/james/conf/james-fetchmail.xml (No such file or directory) cd bin, then run.sh. The default paths are all relative to bin/, which would then be your working directory. Perhaps we should change run.sh to change to $PHOENIX_HOME/bin, and then run phoenix.sh. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Stefano Mazzocchi wrote: First of all, sorry for the massive cross-post, but I think it is going to be a great opportunity for all the communities involved to show off their potentials with the apache infrastructure. The proposal is about the creation of a content management system for apache projects, codenamed Doco +1 from me from the Forrest side. What I really like of this proposal is the SOC, Separation of Concerns between communities. I particularly like Forrest's rols, as it it *exactly* what we have been doing till now. .. Frontend/staging will be Forrest. The idea, in order to satify intrastructure@ concerns is 1) forrest runs on top of the repository and generates a staged version of the web site (not on minotaur!) 2) a cron job on minotaur will a) download the entire site from the staging area (using rsync, wget or similar tools) b) commit it on the site module CVS c) move it on the public site folder The reason for such an inverted architecture is to avoid having an SSH access directly from the machine that runs forrestbot. This guarantees *COMPLETE* isolation of minotaur from the rest of the system. There is *NO* way for somebody to hack into any parts of doco and obtain access to minotaur. The reason for committing a copy on CVS is to allow infrastructure@ to have a fresh copy of the web site in case something happens and Doco is down. [they have expressed concerns about this] +1 to this for now. This is basically what ForrestBot does now, and the only thing needed is to install it on Apache hardware, and separate it in two parts (minotaur and moof). ... 7) install lenya, james, forrest and forrestbot on Moof. Ok, this has TBD, where do we go from here? 6) write the cron scripts for minotaur This is just after. I propose the creation of a new CVS module called cocoon-doco to host the scripts, installation instructions and doco-specific code. +1 I also propose the discussions to take place on lenya-dev, given that Lenya is the community focused on content management. Interested people are invited to join [EMAIL PROTECTED] Ok. Let's now move the task of installing the Forrestbot over to the forrest-dev and infrastructure lists then. When it's working, we'll let you know. [in case of community-oriented you reply to this email, please, keep all listed cross-posted, but in case of technical discussions, please, let's move it over to lenya-dev to avoid mailbombing people that don't really care] -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Joerg Heinicke wrote: Stefano wrote c) the email will have reply-to set to the allow action and a continuation ID. and will have the CC: header set to reject with the continuation ID. So, by replying to the email d) by hitting reply, the workflow will approuve the changes e) by hitting reply to all, the workflow will reject them with no further action Kenny Smith wrote: Hi Stefano, I think the overall concept for this project is pretty cool and very well thought out. The one part that stands out to me as a weak link is the reply vs. reply to all mechanism. It seems prone to human errors and to things like vacation messages. How would conflicts be handled (one person rejects and one approves)? At the very least, I would provide a mechanism that allows changes to be just as easily revoked as they were approved so that late that one night when someone accidentally hits reply to all instead of reply that they can easily fix it. I can only join. Email workflow is bad in general, but additionally the above system is to much error prone. I has worked for the apache group since 1995. Yes, there are occasional mistakes and some message gets moderated thru even if it shouldn't, but compared to the traffic we get this is really nothing. We should at least use the body with an explicite accept and reject in it. This can't be done by accident, while it can happen for sending a mail. But even this I don't like much. What about authorization? only doc committers are subscribed. Are the committers registered with specific mail addresses? of course, how else? What happens if the preferred address changes? they tell us and we change the address. keep in mind that most of them are committers anyway, they will have an @apache.org address that will never change. I would like to see a little application, where a link in the mail points directly to the resource. The committer has to login and accept or reject the change. So conflict situations can also be much better handled and reverting changes should also be easier to be implemented. I dislike this, it stops me from doing auditing offline. This is still much easier than the current workflow with applying a patch, committing to CVS, and so on, but less error prone than the above approach. In the entire history of the wiki, we had only a few cases of severe vandalism on our wiki. That workflow is designed to prevent the vandalist acts but without slowing down the creative process. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Stefano Mazzocchi wrote: In the entire history of the wiki, we had only a few cases of severe vandalism on our wiki. Please don't over-generalize, Stefano. We have weekly 'annoyances' on the Cocoon Wiki ATM, but some people happen to clean them up sooner rather than later. I know the Wiki appears to be running smoothly, but it requires energy and handholding at times - these times even that much that I'm still hunting for some free moment to move it to moof. Ditto with moderation: I have at the very least 20 spam mails and viruses awaiting me in my moderation inbox (from all Cocoon lists) on a daily basis, some days more. That workflow is designed to prevent the vandalist acts but without slowing down the creative process. We definitely need some form of oversight. The current 'mass push' to a mailing list appears to be working quite well IMHO. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] Doco
Stefano, +1 Looks like a good plan that takes the ForrestBot idea, builds on it, integrates other things, seems secure and scalable, provides the opportunity for anyone to help write documentation, but provides multiple points oversight. The proposed workflow institutionalizes RTC, but the project can always revert a change if others disagree with the decision to approve the change. I do think that we want to try to enure that we have sufficient security in the system to prevent someone from making an unwanted change and then spoofing an approval. Perhaps we could require SMTP AUTH over SSL for the moderators? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
