1 2 Previous Next 23 Replies Latest reply on Dec 30, 2004 3:51 AM by pilhuhn Go to original post
      • 15. 3854094
        starksm64

        jBPM is an example of a project we are immeadiately promoting to a supported status because its a strategic build out of the middleware stack.

        A mail server is a prove it to me type of project given there are a plethora of solutions from open source to commerical.

        Both types of projects will be introduced into the JBoss Labs effort. At the end of the day every project has to prove it can pull its own weight.

        • 16. Re: Milestone 2
          iwadasn


          I would like to point out a few things. We are a medium sized company that uses exchange and JBoss. All our really important (business critical) work is done on JBoss, and we're very good at managing these appservers. If someone walked in today with a solution (open source or not) to run our mail servers off of a clone of one of our JBoss appservers, we'd sign up in a heartbeat if it had even a minimum of exchange like support.

          We already basically killed off our old issue tracking system with iTracker, because iTracker runs on a standard JBoss appserver using standard EJB. That means we can connect it to our DBs just like we connect all the rest of our appservers and it just works. No problem. For this very same reason, bugzilla won't even get in the door. We don't use MySQL, and we're not about to rollout apache and MySQL on some random box just for issue tracking. Our issues can reside in the DBs where everything else lives, and it can all be backed up and maintained together.

          This is why James is a non-starter for us. It uses some sort of messed up Turbine based framework that (in my experience) doesn't work at all, and they want to demand MySQL as well, which once again leaves their project dead in the water.

          Basically, what I'm saying is this. Any project that can use EJBs in JBoss to interact with our databases will almost certainly replace any product that cannot, for us. This goes pretty much across the board. Issue trackers (like iTracker), mail servers, bulletin boards, web-mail, calendaring, scehduling, etc....

          I have no idea if we are current customers of JBoss inc., but I bet if someone offered to replace our exchange servers with a JBoss based alternative we'd pay a king's ransom to get some guys in here to perform the migration. That sort of thing should be JBoss's bread and butter.


          • 17. Re: Milestone 2
            mutpup

            I'm not sure how many people realize the need for a good enterprise class mail system.

            Either for corperate mail, or ISP type hosting if the solution is right, people will pay for support.

            This is one of those types of projects that isn't going to get moving in the community until people have something they can use....like Asterisk.

            So, is this project dead on the table, or is Jboss planning on updating the roadmap dates?

            • 18. Re: Milestone 2
              starksm64

              Its in stasis until someone steps up to lead the project.

              • 19. Re: Milestone 2
                komone

                Oh, and another thing (just to put the last nail my coffin of negativity), has anyone actually spoken with the James team or thought about a collaboration?

                /k1

                • 20. Re: Milestone 2
                  acoliver

                  Thanks for your feedback.

                  JAMES is based on Avalon. Avalon is dead. JAMES can't handle my PERSONAL email load without being restarted nightly. JBossMail runs stable (minus my hardware failures which is a longer story).

                  I guess the case for mail services wasn't clear. I'll dismissively throw down the hammer. Here is the state of things:

                  * Javamail - is a total piece of crap. Its slow and over-complciated, the appserver bindings are -- dumb for a serious mail application

                  * JAMES - is based on Avalon which was a very bad (fatal actually) design decision. JAMES is horribly untestable code. JAMES is pathetic and can't be scaled (in part because of Javamail). (BTW I dug into JAMES while figuring out what could be done to implement IMAP ;-) so before you argue know the JAMES codebase and actually RUN it) and thats part of what lead to the JBMail idea. I'd planned to launch a mail server project prior to joining JBoss) -- Because there is so little implementation of value in JAMES, I'm very uninclined to collaborate. There may be room for collaboration on a replacement for JavaMail ( even if it seems like I just like to reinvent everything which isn't really the case hey not having to load the entire mail into memory might be a really neato feature don't you think!) -- the JavaMail interfaces (which really suck BTW) could be wrapped over the new stuff. However, I think of this in the same context of "lets wrap hibernate with CMP" (sure you CAN but you then add a lot of suck to hibernate).

                  * Enterprise-grade Clustered mail servers (of any real market acceptance) - Name them. Really there are two. Domino and Exchange.

                  * SPAM and the STATE of mail - I get more spam than mail and even with the greatest spam tools. Through collaboration with other open source projects we can come up with a system to enhance and exceed current protocols and systems that works for most people. (80-90% of users)

                  * Exchange....well....tool wise and feature wise -- Exchange rocks. Cost and *actual cost*-wise....it's not so hot.

                  * Sendmail/Postfix and the lesser "heavy lifters" of the internet are BITCHES to configure correctly and lack the tools and support of Exchange.

                  *Nothing ever replaced LotusNotes/Domino in mail-driven-application features. I'll detail these after the 1.0 release. For 1.0 in this area we'll work on maillets and mail scripting features as well as J2EE integration.

                  *J2EE/JBoss/Appserver-based applications in which mail is a principal application component -- it does not make sense to send to ONE SMTP server and then another. You need the data on the success or failure in reaching the target SMTP server HERE not in some intermediary. You can kludge your way around this but that's what it is. It is not pretty.

                  I tried to lay that out and the beginnings of a solution in "the case for mail services", but I guess I didn't do as great of a job.

                  Lets address your points specifically:

                  - This project has no planned architecture (let alone design). It desperately needs one.

                  That's simply unfounded. As for a BFUD as the XP crowd calls it, okay thats true... Since I never read those, I don't write them either. Instead there is a pretty clear architectural motif and list of reasonable objectives for the near future. There is a vision document -- hey if it wasn't clear (some "got it" some "didn't"), maybe in a couple milestones I'l revise it.

                  - This project does not have genuine selling point other than that it is "the same old mail services only this time on JBoss" (yes, I have read "the case for mail services")

                  I'm not on the marketing side, this project addresses several problems I've encountered as a mail user, system programmer, application developer and consultant. Its rather early (Milestone 2 will be out in a few days, I'm working on a little install config tool for it) to come up with marketing literature.

                  - This project is too unfocused in deployment of effort and feature delivery (for instance, the integration with Nukes bit - that's way too early to be a target)

                  Its pretty volunteer-based at this point so thats not likely to change in the near future. GO IMPLEMENT BETWEEN COMMAND TIMEOUTS NOW! (http://www.jboss.org/wiki/Wiki.jsp?page=MailServicesMilestone2Timeouts) If you go and do that then maybe I'm wrong in my assumptions, but if you don't then hey I'm taking what I get and guiding folks in their areas of interest along a set of objectives. On the specific example (nukes-integration), I agree. It was a mistake. I hope to have time to make more mistakes in search of the right decisions.

                  - If I see another custom, application-specific user/group management implementation I am seriously going to scream!

                  Yeah, thats why there is only a "StaticUserRepository" in M1/M2 which is kind of a silly implementation (though if you look -- the interface and preliminary design decision is actually pretty clear). Its a placeholder. Someone just contributed a JBossSX-based version. Once M2 is released I'll commit it. I'm toying around with more specific permissions though for IMAP. I hate ACLs to be honest but it may come to that.

                  - It's dangerous (even suicidal) to tie an enterprise application to tiger just yet. For most big enterprises 1.3.1 is still a "standard" JVM.

                  We haven't. I kicked it about, but for now, since I'm on OS X which doesn't even have a 1.5 JDK yet - its 1.4.x. I actually challenge the 1.3.1 assertion. I spend most of my time on the road consulting for JBoss at big enterprises (hence the slow pace of development). None I've visited recently are running 1.3.1 and if they are parallel garbage collection is usually compelling enough. Since the 1.0 release date is still many milestones away, I'm non-committal to stay 1.4 compatible. SSL over NIO would pretty much mandate 1.5. I'm non-committal that we won't change gears and go NIO if my benchmarking proves promising.

                  - No lessons seem to have been learned from the experience of Apache James (the big draw for me in James was the ability to write Mailets, but it failed evaluation for much the same reasons as mentioned above and that have been previously posted in this thread).

                  That is unfounded. We're only at Milestone 2. Lots of lessons were learned from JAMES. I even ripped of the stuff I thought was good. I haven't gotten around to properly ripping of mailets. We're not done finding the tradeoff between how to represent messages as a flexible object model yet maintain high throughput. Support for spam assasin, webmail ,etc are all in the works. The schedule (http://www.jboss.org/wiki/Wiki.jsp?page=MailServicesPlan) changes, the plan evolves based on contributions, availability of people to work on it. Pretty much everything mentioned in the above thread is "stuff that we have planned but haven't gotten to yet". Only we're not tied to a big fat dead mega-framework-philosophy-project-slash-framework that makes everything hard to implement ;-) we just have not even half the people working on it and haven't been at it even 1/10th as long.

                  - Decide first and foremost WHAT DOES THIS PROJECT GIVE AN ENTERPRISE OVER AND ABOVE SENDMAIL etc or EXCHANGE? Find the single line answer to that question that is sufficient to convince anyone whether commercial or technical.

                  It is the compromise between more bare bones mail services such as postfix and sendmail and Exchange. It can work in both situations. Moreover, compatibility with existing Outlook/etc infrastructure with no license fees. Lastly, features which properly support mail-driven applications. I did describe some of the problems we wanted to solve. I don't really hope to sum it all up in one line. That is marketing, I'm not in marketing. My audience for the next several milestones is like-minded geeks.

                  - Focus first on user/group management and figure out how to reduce dependencies to the point where it is NOT destined to be an inextricable module of the mail services.

                  Thats already done. You can plug in different implementations. The present interface is a bit over-simplistic at the moment and will need to grow once we add IMAP. Granted, it wasn't my focus for M1 - for M1 guess what it was "code should run and deliver some mail". M2's real focus was "don't loose mails and stay up reliably". M3 may be features or speed -- haven't decided.

                  - Deliver the IMAP so that a webmail interface could be built.

                  Thats in the plan. Again, thats a big thing to demand on the second milestone. Anyhow, IMAP isn't that hard really. Its just another text-based protocol. Now FAST and COMPATIBLE WITH LOTS OF CLIENT IMAP is certainly some effort. We'll focus on the Mozilla-mail and Outlook clients (we must always have two because they "accept" different things) on the three most used client platforms (Windows, Linux, OS X -- selected in part because I have them all, in part because all three do different things with end of line characters). BTW IMAP isn't required for webmail.

                  - Steal the mailets idea from james - yes, even the source as a start point.

                  I thought you read "case for mail services" -- that was in there :-). However, the code is not useful....honestly. I did "steal" other code from james that was useful.

                  - Look forward a bit and realise that you must ditch ejb2 entity beans and build on ORM (hibernate) - later provide an ejb3 implementation for java 5 when people actually want it

                  Thats actually planned. I was waiting for the Hibernate Deployer and SessionFactory management in JBoss 3.2.6/4.0. Secondly, its intended to be pluggable. (Yes I have a really good reason to need this pluggable). You'll hate this but I think every "pluggable" thing of substance needs 2 implementations to prove its pluggable. Do the easiest one first (and AT THE TIME, it was easier to do CMP).

                  - Drop any other integration effort for the time being

                  With nukes thats pretty much agreed to and done (we had a good reason for doing it but it didn't work out). However, ummmm if I didn't need to integrate, I'd write my own email client gui and drop support for SMTP, POP and IMAP and invent a protocol and convention that didn't require letting unauthenticated users essentially write files to your storage via an unsecured text based protocol that doesn't support compression. Then I could email myself and family members that humored me :-). In short a mail sever is integration incarnate.

                  Honestly what the project needs most right now is more of my time and a few more people. Open source projects are such that (as Scott so coyly pointed out) when the "vision holder" or project lead or whatever is away...the energy bleeds out. Unfortunately, my job and 9-month old doesn't let me spend as much time as I'd like (This year I spent over 50% of my time on the road), but I keep plugging away a little at a time and eventually the ball starts rolling. Patience Iago..patience.

                  Anyhow, while this feedback was helpful (if only to help me realize what is and isn't clear and what is plainly obvious) and I appreciate it I don't really want a whole lot more of the same. From this point I mostly don't want "justify yourself" style feedback as it takes too much time to do. Simply because I want to spend all the time that I'm not on the road working with customers, working with contributors and early adopters and writing code.

                  For those who are interested in contributing, I have tasks which you can complete to help "dive in". For those who think this might fit their needs and are willing to work with me, I can offer some of my time and effort in exchange for yours. Hows that? Its not quite "Blood sweat and tears," but it will have to do.

                  • 21. Re: Milestone 2
                    pilhuhn

                    Andy,
                    wow that was longish.
                    I personally think, JBMail should aim at one goal - being a sendmail/qmail replacement OR being an Exchange replacement.
                    In practice, you don't want to run exchange on a mail-router, while in an enterprise, you want Exchange for collaboration and the use with intra enterprise mail.
                    While sendmail/qmail/postfix are perhaps hard to configure and have their problems, the do run the global email world. I don't say, one can't compete against them, but it will be hard.

                    Wrt database: The JBoss project should perhaps designate a hsql successor and use it always and in all projects. (btw: I don't like mysql :-)

                    Heiko

                    • 22. Re: Milestone 2
                      acoliver

                      thats fine for the shorter term, but long term Exchange is the ticket. You may hate exchange but the people who pay money for service....they love it.

                      Database: you wouldn't be the first to suggest such a thing.

                      • 23. Re: Milestone 2
                        pilhuhn

                        Hm, I have the feeling that you misread my mail.

                        The only thing I say is only address one of the goals at a time (sendmail etc. / exchange). It you try to replace both, then you will fail, as both are best of their kind.

                        Perhaps the JBmail design should be some "horizontal multi tier", meaning:
                        having a simple mail router as a frontend, which also gets exposed to internet etc. This one only knows how to route mail and to refuse mail to unknown receipients / from spammers ... The second tier would know how to route mail to the first tier and else only be able to route internally between known users. Communication between the tiers could go over JMS, but also over smtp to allow to use e.g. sendmail for the first tier and JBMail for the second one (or the other way round with JBMail/Exchange).

                        I don't know why you got the impression that I'd hate Exchange.

                        Heiko

                        1 2 Previous Next