Re: Server statistics (was: Personal IP blacklists)
Note that on its face JMX is a services framework similar to avalon but with less cruft and without the compiler-time checks (for better or worse). My stuff is a JMX SMTP Service for Jboss + later I'll do POP, IMAP and Exchange... If you know who I am, you know I'm the guy to do such a crackheaded thing. -Andy On 6/16/03 5:45 PM, Richard O. Hammer [EMAIL PROTECTED] wrote: A week or more ago on this list I saw mention of JMX http://java.sun.com/products/JavaManagement/, though I did not pay close attention to that thread, so perhaps I'm repeating something here. I've read the first 15% of the JMX spec, and I have the impression that JMX is intended for uses such as monitoring server statistics and setting server control parameters, such as number of incoming connections per unit time and others which I listed earlier. I imagine that the class doing the work would have a variable which holds the statistic we care about. For instance SMTPHandler might keep an int connectionsDuringLastMinute, which value could be sampled and displayed on a little gauge like the temperature gauge on the dashboard of my car. Similarly, that class could have a control variable, an int connectionsPerMinuteLimit, which the administrator could set, if needed, with a knob (or the best GUI equivalent) right under the gauge. This would cause SMTPHandler to refuse or defer some incoming connections. That class might also keep a SortedSet of the IP addresses currently sending in the most mail, giving the administrator ability to limit the incoming rate from any given IP, just as easy as closing one of the windows a little bit in a car with electric windows. Logging comes to us from an age before GUIs. It still serves some purposes well, but, for managing current, ongoing problems, much better pictures and real-time controls are within reach (hopefully speaking). Anyhow, do others think of JMX as useful for such monitoring and control? Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how hard is it to write a SMTP client?
At some point we might all meet up in Commons. There are many places where JAMES exceeds or fails to meet some general mail service uses. However, not yet. Let some divergence happen then find areas of agreement. -Andy On 6/6/03 12:41 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: Richard, Classpathx has an GPL implementation of JavaMail. You could look at it. With respect to writing your own SMTP client, it is simple for simple cases, but the totality of SMTP isn't simple. However, I don't see why you can't use James for your application. What you are proposing seems like a fairly straightforward custom application of James. From what I read on your site, and from your post, it is essentially a variation on a TMDA (www.tmda.net/) scheme, but requiring payment rather than authentication. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how hard is it to write a SMTP client?
Hi Richard, Do you mean to say an SMTP client using JavaMail or an SMTP client not using JavaMail? Why would you need to write a replacement for JavaMail for sending mail? In any case, do you have a copy of the SMTP spec? I'm on a plane so I can't reference it right now, but IMNSHO, it should be fairly easy. Especially if you use the telnet library I used to create my james-shutdown utility which you can find linked from my homepage (http://cvs.apache.org/~acoliver) with source. Still I feel you'd be better advised to not re-invent JavaMail itself. Writing something that pulls a mail from a mail server with JavaMail isn't too hard. -Andy On 6/6/03 12:21 AM, Richard O. Hammer [EMAIL PROTECTED] wrote: Following Andy Oliver's lead, I will tell that I too am working on a mailserver project with goals so different from those of James that I am trying to develop a separate body of code. My goal is to offer a an email service through which unknown senders will be allowed to send their messages only after they have posted bond. If you are curious, you can read more about this at http://mailscreen.net. I find the code of James valuable as instruction and example, and I hope to be able pay back with contributions wherever my project overlaps. On that vein, has the possibility of writing an SMTP sender to replace javax.mail.Transport been considered? It seems to me that it may not be very hard to write that side, although I have not tried and may be mistaken. I read that Sun intended JavaMail for SMTP clients but not for servers (probably I read that in either the API or the specification). That may explain why the JavaMail API sometimes seems so difficult to use as a utility for an MTA. (For example, it seems silly to me that I must create a Session (or a Folder) before I can parse an incoming MimeMessage.) Anyhow, my questions are about writing an SMTP client: does it appear to be a difficult undertaking? has it been considered for James? Thank you, Rich Hammer Hillsborough, N.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how hard is it to write a SMTP client?
On 6/15/03 6:45 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: Why would you need to write a replacement for JavaMail for sending mail? I don't need to as much as I hanker to. Have fun. I concur with Noel...not particularly pointful, but have fun. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Understanding the SMTPHandler Data method
Doh... I accidentally tapped the touch pad and sent that before I was done editing it. I was just going to make it sound better...sorry.. :-( -andy On 6/5/03 9:34 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Thanks, I think I understood that. The other explanation posted I think answered my question (regarding the headers eating the crlf). My objectives are really offtopic. I'm writing an SMTP JMX service which interacts with message queues/topics in Jboss. POP/IMAP will come later. Note that I don't wish to debate JMX vs Avalon, J2ee, JMS or any of that... Please reference me your mail on handlers, I couldn't find it. I'm following the command pattern with it. Each command gets its own class delegated from the handler. Mail mail = Mail.create(msgIn); This is a change to the Mailet API, not the James server implementation. We do not want to see the Mailet API balkanized. Do what you want with the org.apache.james.* packages in your fork. In the above case, you could do: Mail mail = MailImpl.create(msgIn); and no one would care. If you do feel that it is necessary to change the Mailet Specification, please bring up your proposals for discussion. No worries, I'm not using the mailet stuff, just happens to also be called mail. This isn't an area I'll likely collaborate on. Like I said, I don¹t want to debate. I'll be taking code for my stuff, and I'll donate back where I can. -andy --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Sascha Kulawik wrote: No I'm afraid that the code will be merged without the test cases. Anyhow all I said is that the test cases should move with the code. Yes there are testcases that do not run now. That is not an issue. For this type of development I personally prefer test-first design. (meaning capture a subset of the spec or some mail client behavior and record the expected responsesTHEN make it actually so) It isn't easy as it seems. Within the FETCH Command you have a whole \ No its really easy to make test cases for this. Check it out. -Andy different possiblities for getting the Body, as I've seen Mozilla does not especially declares, that he wants to get the body of the mail - thats the point why it currently don't views the message content. I think, today or tomorrow I'll will be ready with that. The other point is the Append command - in some cases not all of the header-fields are correct submitted. I like testing with something living, like a real mailclient. Thats why I haven't checked the test-cases yet. IMHO Stephan wanted to check all of the test-cases. Regards, Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Fetch Command now working with Mozilla
Sascha Kulawik wrote: Hello, Here is the new CommandFetch for a working Fetch with Mozilla. Haven't made a diff, diff says to me: every old line out, all new lines in - doesn't seems useful for me. Regards, Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] invest in the command dos2unix assuming you're using cygwin. if on linux do: cat myfile | tr -d '\r' myfile That will convert the line feeds. For me (reading from mozilla on winblows at the moment) your attachment became a winmail.dat file. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Danny Angus wrote: I think for the purpose of ensuring that we're compatible with actual IMAP and not MSIMAP (probably a tm) having Mozilla or Eudora, etc should be the guiding principal for judging this. This is however far less important to me than the unit tests issue. I think they are essential to a high quality IMAP implementation and I'm not apt to waste my time creating low quality anything. No, fine, I completely agree. What I would say is that IMHO it isn't necessary to wait until we have a 100% sparkling product ready before we start to include it in James HEAD or in standard distro's, given suitable disclaimers. Oh I totally agree with that. My only issue is that SOME client other than outlook should be able to list the folders and get a message. In fact I believe that its inclusion would help to encourage the development effort, provide useful feedback and enlarge the team of active participants. We all know how to judge stds compliance, and I agree that unit testing is the way to go with regard to formalising this. But its also true, as we've already seen in James, that expected behaviour, and indeed normal practice isn't always completely aligned with standards' specifications, so to gain market share you have to support both the std and the expected non-std situation. Of course! And writing unit tests that mimic abberant behavior of say Outlook or Mozilla for instance is a good way to test these. I'm strongly of the opinion that these two different drivers, standards compliance and operation in real-life situations will drive development forward in unison, with no question about reduced quality. The standards based approach is being tackled already, the real-life drivers will appear once we start making access to IMAP easier for end-users. agreed. My main point being that I don't believe we have to claim the product is complete, just that it will provide some basic semblance of operation for us to start to make it available, I don't see why we shouldn't aim for a high quality IMAP implementation yet still release work in progress early and often, and get feedback from potential users. agreed. My issues: 1. Some client other than outlook (preferrably one that runs on some *nix) should be able to list the folders (that works) and get some mail (nope) 2. The unit tests must go with the code. I totally agree with everything you said. -Andy d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Danny Angus wrote: Oh I totally agree with that. My only issue is that SOME client other than outlook should be able to list the folders and get a message. Oh, fine, we're just splittin' hairs then :-) I think so yes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
On Mon, 02 Sep 2002 10:29:48 -0400, Danny Angus wrote: No I'm afraid that the code will be merged without the test cases. Anyhow all I said is that the test cases should move with the code. Oh, yeah they'll move with the code. IMAP was in the HEAD with its tests (I think) until quite recently, but we backed it out owing to lack of progress. d. Then I'm happy with that :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Sascha Kulawik wrote: Eeenteresting. I'll take a look but I tried to build it 2 days ago and I had a holy heck of a time getting it to build. the build-imap.xml file seems to be expecting a drastically different directory structure and locations than the HEAD. it pre-dates big changes that were made to upgrade phoenix. The changes are done - and it was comitted on Tuesday. Ehhh? I check out the head and it doesn't work. I don't yet have time to sort this out but my plan is this: 1. Get build-imap.xml and build-test.xml to work out of the box when checking out the head -- submit this +1 The build-test.xml will be done by Stefan Schiessling, I'm not a ANT-Wizard, so I havent changed the build-file for the IMAP trunk. But is this needed, if IMAP will be in the Main trunk ? It is needed to prove IMAP should be in the main trunk. 2. look into what it would take to move it into the head and submit that ensuring its fully turn-offable Basically its not hard, its a conifg thing, but we *must* be able to deal with whatever the conflict in james.java is. I still don't think we'll be miving it back into the HEAD until its been shown to build *and* work, at least to some degree. (I can't get it to work) If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. I have no need for email viruses. No chance I'm installing that piece of junk on one of my machines. -Andy Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Danny Angus wrote: If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. Sascha, If I compile James with IMAP will James be exactly the same in operation if I don't enable IMAP, than James without IMAP compiled in? If the answer is yes, and I can make it work with at least one IMAP client then I'd be prepared to vote in favour of moving it back into the HEAD. Not that my opinon should matter much, but I'm -1 unless the test cases go with it and can run (I'll help as much as my abillities allow). I consider them absolutely crucial to having a solid standards-compliant implementation. Currently it does not work with either IMAP client I have access to Mozilla or Ximian. -Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Danny Angus wrote: I think I'm learning this. I gave up for the night after a few hours of trying to solve phoenix barfing and telling me what to do. I'm probably going to try the reverse. Copy build.xml over build-imap.xml versus trying to solve all build-imap.xml's issues and try and figure out what needs to go in it to make it build the imap stuff. This should be fairly simple, I don't think there is anything IMAP specific about the IMAP build, except that it is a fork of an older build.xml file. There are a few things in it specific to the proposals dir, etc. Here is what I have to do to get it to work: 1. check out the 2.03a branch 2. muck with those (inc the normal) build files until they can actually find ant on unix as advertised (the docs and stuff LIE LIKE DOGS, I just don't know what of my tinkering actually worked) Some of the docs are way out-of-date since the phoenix changes came in. At some point if I get stumped would you be willing to take some patches to the build, and see if you understand the phoenix issues its griping about? Yes. if you have easy to reproduce breakages I'd be happy to give you pointers, but no too much time to fix stuff myself. Great. Thanks. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] IMAP - Append Command
On Sun, 01 Sep 2002 11:51:37 -0400, Sascha Kulawik wrote: If you copy the files out of the proposals directory and inside the main directory and upgrade the needed files that are redundant with the main trunk, it will be full functional. (After that compile James as like without IMAP). Currently Ive tested with Outlook and Outlook Express with no bigger problems, so you can test all of the features. I have no need for email viruses. No chance I'm installing that piece of junk on one of my machines. No probb :) I'm developing under Windows, so it was the easiest way to test the IMAP functionality. I've also a Linux Box here and will test the features also under Evolution, Kmail and Mozilla. You can also use Mozilla on Windows. -Andy Regards, Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
I think you're right and we're ready, but we need to get IMAP up to the same dependency tree as the head. It still won't build with it. -Andy Sascha Kulawik wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver Sent: Wednesday, August 28, 2002 2:40 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] IMAP - Append Command Personally, I think we should look for a way to componentize JAMES far enough to where building in IMAP is as simple as flicking a switch so that there is no need for a divergent versions of things. It IS currently possible to switch imap off or on - compiled in the main trunk. So it also would be possible to let the IMAP-Trunk reside inside the Main-Trunk. Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Cool. Then it sounds pretty sensible to move it to the main trunk at this point. Sascha Kulawik wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew C. Oliver Sent: Wednesday, August 28, 2002 2:40 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] IMAP - Append Command Personally, I think we should look for a way to componentize JAMES far enough to where building in IMAP is as simple as flicking a switch so that there is no need for a divergent versions of things. It IS currently possible to switch imap off or on - compiled in the main trunk. So it also would be possible to let the IMAP-Trunk reside inside the Main-Trunk. Sascha -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] IMAP - Append Command
Personally, I think we should look for a way to componentize JAMES far enough to where building in IMAP is as simple as flicking a switch so that there is no need for a divergent versions of things. -Andy Danny Angus wrote: Sascha, I'm happy to work with you to get these changes in, then to assess IMAP and propose a vote if it appears to be half way stable, but 1/ please could you help me by making your patches conform to the guidelines http://jakarta.apache.org/james/contribute.html diff -u from the /proposals/imap dir, and zip new files from there too. Then I don't have to work out paths, and go looking for files to patch. and 2/ Perhaps if I add a task to the main build file that will build James with IMAP that would be a reasonable interim before we put it back into the HEAD. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
James' code isn't undocumented, but there are various uncommented members, so Peter is trying to complete the documentation. The same can be said of org.apache.poi. For example, AbstractFunctionPtg is missing javadocs for a number of members. I'll bite... While this is a tad offtopic... soap-box For one, some of the members are deliberately uncommented (I don't do inherited members as the javadoc will override the parent's). However, POI will not have a release with formulas enabled by default until its fixed. It will have development builds (alphas or milestones) until then, but thats it. Why: its not of release quality. As evidence, formula support is still in early beta. So Noel, how long did it take you to find a class to use as an example, or did you just go down the left nav in alphabetical order? That one is a few layers deep and in the most beta of code! I'm impressed at your resolve! If you can find others I'll make a list of them and make sure I catch them all before +1'ing our next release. To take THAT a step further, some of the committers of POI would like a policy of requiring a unit test per class before release! That will likely pass for our 3.0 release. We'll probably need a few enhancements to Centipede to support test-first a little better before we draft that. Just FYI, the policy on this is covered here: http://jakarta.apache.org/poi/resolutions/res001.html and more or less here: http://jakarta.apache.org/site/source.html Its a quality thing. /soapbox Anyhow, I'm just a guy trying to make hide or hair of james. My opinion shouldn't count for much, but I'll NEVER understand your position that javadoc isn't important enough to hold up a formal release. (I already said milestone and dev releases are reasonable, but I don't think YOU gave it a close read) Thanks, Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: James End User Documentation
On this we can all agree... wikis are very powerful tools for generating documentation. I'm very impressed with the progress made on the Cocoon wiki. Stephen Noles (sp?) will be very suprised when he gets back from vacation. -Andy Noel J. Bergman wrote: Nicola, Assuming that folks vote for a wiki, can we set one up on apache, or did this require a server elsewhere? I like wikis. Been running vqWiki on several projects. --- Noel -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 15:25 To: James Developers List Subject: Re: James End User Documentation Noel J. Bergman wrote: solicit away. 1. Can we agree on some [DOCUMENTATION] prefix that people can use, so that documentation submissions can be located in the archives? 2. How's: If you have James related tips, documentation bits, or just questions about things that you need help with, please submit them to the James project with a [DOCUMENTATION] prefix on the subject. The more contributions, the better the user documentation will get. I don't supposed anyone on the list is a tech writer, eh? :-) I'll post up an example of multiple mailing lists so that people can see what needs to be done for EACH new mailing list. The current documentation isn't clear on that (in fact, mine works but perhaps I missed a point). On the Cocoon project, we have already done this. We started asking to commit doc stuff with [DOCS], then we moved to asking to put them in Bugzilla. Finally we set up a Wiki, and this last solution brought us more documentation inh a week than the other two in a month! -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
Vincent Keunen wrote: Thanks Peter, for your message that makes things move forward. I'm adding some comments about the specific item of javadocs. First, I must say that I agree with 2 comments from Noel: Internal Documentation Absolutely necessary. But NOT to hold up the 2.1 release. We can continue to upgrade the web site with new documentation, and any serious developer should be working from the CVS I disagree. You wouldn't release Documentation with no code would you? Why would you release code with no documentation? If documentation isn't a condition for release, you'll never do it. So say what you mean Absolutely someone else...the mythical someone else..should document JAMES, but quality is not important to me so I'd rather get it out the door undocumented and hope the mythical someone else comes along javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes, we need to work on the javadocs, but I would not wait for them before putting out a stable release build if we can do so. retranslate: Code quality is not important Peter M. Goldstein wrote: Internal Documentation I know some people tend to dismiss internal documentation, but I don't see how a project that is seeking to attract developers can function without it. As such I tend to include it in the exit criteria for a particular release. 1) All methods and instance variables should be documented. All classes should be documented. The documentation doesn't need to be extensive, but it should be present. It should include issues such as class/method contracts and threading restrictions where appropriate. 2) All public and protected classes, methods, and variables need to be documented using Javadoc style to ensure appropriate Javadoc 3) The Javadoc should build without warnings 4) All packages should have package documentation Peter, I'd like to modify a bit your suggestion. From my experience (15 years of OO software developement), doc should be reduced to the minimum (and I find XP discussions about documenting the code quite appropriate to modern developments). Some ideas: * code is the only thing that really lives; it changes often (writing docs is time consuming and is very difficult to keep in sync with the code; and out of sync doc is useless, and may even lead you to wrong assumptions...) * the code (at the class/method level) should be self explicit: if you need doc to explain code, think about rewriting code to make it more explicit; also, good developers read code almost as easily as the doc (if the code is good, of course) * doc is very useful at the package level: what does this package contain, where to look first (important classes and methods should be mentionned) * important classes/methods may need some doc * important here meaning part of an API, important for external developers or part of the basic building blocks of the system, that all developers should be comfortable with I really don't want to start a lengthy discussion on the pros and cons of documentation (see the forum related to that), but I believe that docs should not get in the way of developing fast (especially on a volunteer basis, with restrained resources). And I am convinced that it won't hurt the project's perennity... Just my 2 cents (and I hope I did not offense you, Peter). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
Well said Peter. If your on Advogoto I'd love to upgrade you. -Andy PS... very offtopic Furthermore de-emphasizing documentation is one of my key beefs with XP. While I hate 300 page specs, I hate 0 page ones too. Peter M. Goldstein wrote: Vincent, I'm not offended, although I disagree almost entirely with your points. :) Basically I feel that on distributed, volunteer projects extensive and appropriate documentation is even more important than on projects being done by a full-time, localized development team. And I feel that it is extremely important even in the latter case. While XP is an interesting methodology, James is in no way an XP project. We are using none of the XP techniques (pair programming, rapid rotation of developers to different parts of the code base, aggressive refactoring of unclear code etc.) that make internal documentation far less important. And as observation of the changelog indicates, leaving javadoc out vs. adding javadoc has not made the development any faster. I believe that one of the essential things an open source project must do is attract developers. You do that by making the projects interesting, and the code easy to understand. To me, that means internal documentation. That's what allows a new developer to come up to speed in a very short time and participate productively in the project. And on this point at least the Apache code standards seem to agree with me. :) I also suggested that the internal documentation be tied to a release because: i) That way it actually gets done ii) When the release announcement spurs a few developers to take a look at the code base, they'll find a well-documented, inviting code base. I'd be happy to continue this discussion offline, but I stand by my original wish list entry. --Peter -Original Message- From: Vincent Keunen [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 18, 2002 7:13 AM To: James Developers List Subject: about javadocs (was: Re: FW: What do we need to release 2.1?) Thanks Peter, for your message that makes things move forward. I'm adding some comments about the specific item of javadocs. First, I must say that I agree with 2 comments from Noel: Internal Documentation Absolutely necessary. But NOT to hold up the 2.1 release. We can continue to upgrade the web site with new documentation, and any serious developer should be working from the CVS and At least get the javadoc complete. javadocs are for developers. I view 2.1 as a RELEASE build for users. Yes, we need to work on the javadocs, but I would not wait for them before putting out a stable release build if we can do so. Peter M. Goldstein wrote: Internal Documentation I know some people tend to dismiss internal documentation, but I don't see how a project that is seeking to attract developers can function without it. As such I tend to include it in the exit criteria for a particular release. 1) All methods and instance variables should be documented. All classes should be documented. The documentation doesn't need to be extensive, but it should be present. It should include issues such as class/method contracts and threading restrictions where appropriate. 2) All public and protected classes, methods, and variables need to be documented using Javadoc style to ensure appropriate Javadoc 3) The Javadoc should build without warnings 4) All packages should have package documentation Peter, I'd like to modify a bit your suggestion. From my experience (15 years of OO software developement), doc should be reduced to the minimum (and I find XP discussions about documenting the code quite appropriate to modern developments). Some ideas: * code is the only thing that really lives; it changes often (writing docs is time consuming and is very difficult to keep in sync with the code; and out of sync doc is useless, and may even lead you to wrong assumptions...) * the code (at the class/method level) should be self explicit: if you need doc to explain code, think about rewriting code to make it more explicit; also, good developers read code almost as easily as the doc (if the code is good, of course) * doc is very useful at the package level: what does this package contain, where to look first (important classes and methods should be mentionned) * important classes/methods may need some doc * important here meaning part of an API, important for external developers or part of the basic building blocks of the system, that all developers should be comfortable with I really don't want to start a lengthy discussion on the pros and cons of documentation (see the forum related to that), but I believe that docs should not get in the way of developing fast (especially on a volunteer basis, with restrained resources). And I am convinced that it won't
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
I totally disagree with just about everything Noel said except for the end. Development builds milestone builds or whatever, should not be delayed for quality concerns. It just can't be blessed as a release. As long as everyone understands that documentation is as important as code and that poorly documented code is just pure rat dung. IF you don't Javadoc, you are a crappy no good developer. Code complete, means docs too. Noel, you're wrong, once releases are the gold standard developers care. What good is a release to a user if he can't make hide nor hair of it? If I weren't a semi-decent Java developer I couldn't even set up JAMES. That puts JAMES a bit behind most other mail servers. If a developer doesn't care about that, then there isn't much he could care about. I've seen projects where the documentation was tied to the *real* release and the developers DID care. -Andy Noel J. Bergman wrote: Peter, I agree with almost all of your points. The only ones that I disagree with are: observation of the changelog indicates, leaving javadoc out vs. adding javadoc has not made the development any faster. I disagree, in a way that you'll like. I think that accurate javadocs facilitates development. I also suggested that the internal documentation be tied to a release because: i) That way it actually gets done Only because you want to get it done. Practically, it just doesn't work that way. Developers already have access to the current code, so if they don't care about the javadocs, holding a release up isn't an incentive for them to do it. And you don't need the incentive, you are doing it anyway. ii) When the release announcement spurs a few developers to take a look at the code base, they'll find a well-documented, inviting code base. I support that goal. As I said in another e-mail, let's put out a 2.1a2 Milestone Build to replace the ancient May 30 2.1a1 Milestone, and I'll feel much better for our end users. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
No, I'm pragmatic and you just don't like it. This isn't about some ivory tower notion of what makes good code. This is about lots of James users who are stuck using buggy code and bad documention while we sit here using the good stuff and arguing over when to deliver it to them. What good is a release to a user if he can't make hide nor hair of it? If I weren't a semi-decent Java developer I couldn't even set up JAMES. I agree with you, but what does this have to do with javadocs, Andy? Talk about end user documentation and we'd be agreeing, because what good are javadocs to the average user? Its the whole package. Code complete. You're not pragmatic. Undocumented non-quality code is NOT pragmatic... in fact: http://www.pragmaticprogrammer.com/cgi-local/pragprog?FailureHowTo Fine to release a development build, but don't lie and call something a release, you do everyone a disservice. -Andy --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: about javadocs (was: Re: FW: What do we need to release 2.1?)
To be honest Tetsuya, it makes me scared to use it. Javadoc to me is so basic and takes so little time, to actually argue against it... To me this is the same as an argument to write variables a1, a2, a3... Its code quality. This is an active argument for poor code quality and I can't believe this is controversial! Tetsuya Kitahata wrote: On Sun, 18 Aug 2002 20:40:35 -0400 Noel J. Bergman [EMAIL PROTECTED] wrote: Everyone is agreeing that the documentation is necessary. But javadocs for developers is not a reason to hold end users hostage. I love this sentence, But javadocs for developers is not a reason to hold end users hostage. I think documentation is VERY important, however, in my position just exernal documents (for users) not necessarily internal ones (javadocs). Sorry for the interruption. -- Tetsuya Kitahata [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Introduction
On Wed, 2002-01-30 at 05:12, Danny Angus wrote: Andrew Scott, Hi, I think the notion of pursuing Exchange is a sound one, it was the possibility of building collaborative tools that was one of the main attractions of James to me in the first instance. I'm glad to see Andrew take an interest because, having seen POI (well the docs at least ;) I think he may be the man to ask about Outlook, I've been frustrated for a couple of years at my inability to generate or read the binary email attachments Outlook uses to deal with folder subscriptions, calendar items, tasks etc. So one thing I'd like to see would be a pair of xlation mailets which could take outlook item emails and translate them to xml, and vice versa. Then James' mailet implementation could distribute these, thereby creating a bridge between Outlook and other applications. Unfortunately not only do I not know enough about Outlook, but I also don't really know where to start reverse engineering these mails. Looks like I'll be learning a lot more about outlook. I'll betcha these are written in ole2cdf... :-) I'm a commited believer in the potential of James, it has some real killer features IMO, and to make it swappable with Exchange seems like just the right mountain to climb (or fall off?) About myself.. I don't know enough about Avalon (yet) but I do know alot about email, I've been a comitter here since September last, and if I ever find the enough time I want to add virtual hosting to all protocols, and a mailet context to NNTP. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Introduction
And I've joined to help him in anyway I can. I'm new here, my project POI was recently accepted into Jakarta and I'm in the midst of the transition. I'm now a committer on Lucene as well. I'm strapped at the moment, but as that improves I'll be happy to add more cycles to assisting in this effort. Thanks, Andy Oliver On Tue, 2002-01-29 at 16:00, Scott Sanders wrote: Hi all, A little introduction: I am a die-hard java/xml/xslt geek, with 10 years of OO experience, delphi being my language prior to java. I have always been handcuffed to the MS platform, and have recently started to try and remove M$'s hands from my wallet ;-) I was just involved in a lively discussion on general@jakarta about JAMES being a possible Exchange competitor. Having used JAMES over a year ago, I think that this is possible. I think that JAMES will be a winner regardless, but I would like to step up and try to add collaboration abilities to JAMES in order to be able to replace Exchange and have all the functionality that Exchange does. I am not a comitter here, although I am a committer on commons and alexandria. I have not looked at the JAMES code completely, nor at the Avalon code completely. I intend to start doing this now. I would like to start looking at the JAMES source and the Avalon source, and then start contributing patches the the JAMES code to start enabling groupware functionality. What do you guys think? If this is acceptable, I would like to start, and then also create the necessary plugins to Outlook to make Outlook act as it does, yet use JAMES on the backend. What do you guys think? Cheers, Scott Sanders -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Introduction
On Tue, 2002-01-29 at 16:24, Scott Sanders wrote: Thanks Serge. Having done job after job where Outlook was REQUIRED, and unable to find an OSS solution to the groupware thing where Outlook was supported, I think this needs to happen. Now is the time. Here is the place. The world will thank us later, hopefully before we have died ;-) +1 If not then it'll still be wicked fun. I laughed out loud when I saw the POI homepage. I too subscribe to the 'if M$ pays me enough, I will stop doing this', so I think Andrew and I will get along just fine. :-p. One of my life long goals is to make Bill Gates at least $1,000,000 poorer. If that means I'm a mil richer all the better! (besides then I'd not work and devote all my time to my family and different java projectsOr adding java features to D -- looks like a cool language). I also wanted to note that James Pricket, the original author of the icalendar code, has come back to Apache to continue the development of it. This will go a long way in helping to do the groupware thing. Jeff, if you are listening, welcome back :) Scott -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 1:23 PM To: James Developers List Subject: Re: Introduction I love the idea. I've always wanted the calendaring and groupware features, but could never bring myself to install Exchange and deal with the security issues. I don't have lots of time now, but I hope to continue to build on the mailet/SMTP part of code and perhaps help with the IMAP and whatever else once it's more stable. Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ - Original Message - From: Scott Sanders [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 4:00 PM Subject: Introduction Hi all, A little introduction: I am a die-hard java/xml/xslt geek, with 10 years of OO experience, delphi being my language prior to java. I have always been handcuffed to the MS platform, and have recently started to try and remove M$'s hands from my wallet ;-) I was just involved in a lively discussion on general@jakarta about JAMES being a possible Exchange competitor. Having used JAMES over a year ago, I think that this is possible. I think that JAMES will be a winner regardless, but I would like to step up and try to add collaboration abilities to JAMES in order to be able to replace Exchange and have all the functionality that Exchange does. I am not a comitter here, although I am a committer on commons and alexandria. I have not looked at the JAMES code completely, nor at the Avalon code completely. I intend to start doing this now. I would like to start looking at the JAMES source and the Avalon source, and then start contributing patches the the JAMES code to start enabling groupware functionality. What do you guys think? If this is acceptable, I would like to start, and then also create the necessary plugins to Outlook to make Outlook act as it does, yet use JAMES on the backend. What do you guys think? Cheers, Scott Sanders -- To unsubscribe, e-mail: mailto:james-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
