I think I'm going to stop flying altogether if I have to get checked by bees.
What happens if you swat one of them? They try and charge you with killing a federal officer if you kill a police dog, so what about the bomb-sniffing bees? Would I find myself in the federal pen for smashing a bee?
On a more serious note, what if the bees all swarm over the bomb-disposal equipment instead of the landmines? The article says that they are just looking for DNT particles, in the parts per trillion range, so wouldn't this be present on the bomb-disposal equipment?
There's other features that this type of collection of software would lack compared to MS Exchange. There's things like the addressing support -- Exchange isn't limited to SMTP addressing, as it can handle groupwise addressing, ccmail addressing, X400 addressing (which it uses natively), or virtually any other addressing format with an appropriate plugin. While this isn't critical for single site installations, it makes multisite installations easier because SMTP addressing isn't tied to DNS. There are ways to do this with straight SMTP, but they are fairly complex.
You can do this with Sendmail. That's one of the reasons I still support Sendmail rather than some of the 'easier to maintain' MTA's. Sendmail is very versital WRT handling non-SMTP systems. But personally I can't think of any mail non-SMTP mail systems that don't include an SMTP gateway still.
Directory replication/address book: Exchange makes a copy of the directory of any connected "sites". This means they're always available in the global address list, and trying to send mail to a non-existant account instantly returns an error, even if the remote 'site' server is down.
OpenLDAP has slurpd which is an LDAP standard method of replicating directories. This feature achieves the same functionality.
"Single Instance Store": If you send a 3MB attachment to 100 people on an Exchange server, you don't consume 300MB, you consume little more than 3MB. Most MTAs can't handle multidelivery like this, and instead send an individual copy to each recipient. With ACLs and hard links, and a yet another mailbox format (separating headers and message body), you might be able to do it strictly with the file system. Lacking all of those options, the only other real alternative is to do it in a database like Exchange.
Cyrus IMAP does this. It's a function of the MDA, not the MTA.
Plugins, etc: With Exchange, you can write plug-ins and addons that interoperate with all parts of the Exchange system. Using all these separate packages, each with a different configuration and method of doing things may mean you have to make several different plugins each with a different API and language preference. If I want to plug in a foreign mail system, things get much worse. Now, I have to write some kind of gateway, and try to encapsulate the foreign addressing system into SMTP addresses and convert the messages to MIME (which would have to be done anyway). Then, I've got to write some kind of gateway for LDAP, so the foreign users show up in the directory, and read the directory, and do the reverse for the foreign system. Now, before you try to tell me that no one uses these types of systems anymore, keep in mind that a foreign system could be a fax system, X.400, voicemail or virtually anything else.
The only place I think you have a point here is the configuration mechanisms. I've long though that most of the server daemons should provide a CORBA interface to server configs, so that you could manage them on the fly and do so through a more common API. Sendmail has the interface for the foriegn system conversions, and Cyrus has an interface as well, it all depends on where the interface with the foriegn system. Quite frankly though, I'm not interested in supporting systems that don't conform to IETF standards. That's how the internet works and has created the innovations we've seen thus far. Proprietary standards for network traffic have lost. I feel perfectly comfortable telling people to go get standards compliant if they want to talk to me over the Internet. I doubt Exchange will continue to add support for weird legacy systems it doesn't support already. Most of the legacy support you mention was added when Exchange was new and had to compete and integrate with these systems. I do however think it is important to write conversion tools that allow for easy migration from non-standards compliant systems.
Now, there are quite a few things that would be nice about what they've already decided on doing. For example, there's no single database to get corrupted in their system. And seeing how I've had to deal with a corrupted Exchange database twice in the three years we've been running Exchange, and both times it was PAINFUL to recover. A single corrupt page in an Exchange database makes it impossible to back up the database, and if the corruption is in the wrong place, the repair utilities can make things worse. So, storing stuff in the file system directly is basically a good thing, although it has drawbacks, as I mentioned above.
Cyrus and OpenCap both use Berkley DB4, which has proven itself time and again. I feel comfortable sleeping at night knowing my data is in that format and I have good backups. That's the beauty of this system. It's a number of different projects, yet they all talk together using IETF standards. They reuse common pieces to achieve their specific needs and this makes it easier to understand all of the apps invloved once you understand one of them.
Since none of the legacy systems you mentioned are entrenched like say SMB is in file and print services, I don't see any reason to waste time supporting them. The system I outlined would use the following Open Standards:
SMTP IMAP/POP3 SIEVE (server side email filtering: IETF) SASL (authentication and authorization: IETF) LDAP LMTP (local mail transport protocol: IETF) NNTP CORBA (OMG) SOAP (W3C?) WEBDAV (W3C) CAP/iCal/iMip/iTip (IETF Calendaring protocols) SIP (instant messaging/voice over ip/voicemail: IETF)
This could be provided using the Vocal project and Jabber projects.
The difference would be that this project would require people to conform to Open Standards, which is why we have the Internet today. There is no compelling reason for widely used messaging systems to invent their own protocols at the expense of becoming and island. Those who invested in proprietary messaging systems will be forced to upgrade at some point anyway to continue talking to the rest of the world.
I have read about it, twice. I've also read about a lot of other systems, this particular subject has been a bit of a passion for me. The non-legacy support is via WebDav... essentially the same thing as FTP just over HTTP. They are not using CAP anywhere.
They are not using LDAP everywhere, either. They are storing the free/busy lists on the filesystem via WebDav or FTP, not that this info should be stored in LDAP. They are storing the user account info and the address book info in LDAP, which is as it should be. OpenCAP is storing the calendar data in a db format (looks like berkley db currently) with LDAP support for users.
You've missed the point of my post. It's soley about the calendaring. I think you'll find that I agree very much with their choice of Cyrus and OpenLDAP. I also find the reason for their choices for a "quick and dirty, works with today's client's" acceptable for the interim. As I said, "It's a nice start.".
What it is not, is an "Exchange Killer", nor will it be till it supports CAP with a design like that of OpenCAP. Essentially you need to integrate:
an MTA: preferably Sendmail, due to extensive LDAP and TLS support Cyrus IMAP: for POP3/IMAP/NNTP gateway, cyrus uses SASL and LDAP allowing integration OpenLDAP: user accounts, address book, sendmail routing info, alias lists, etc. OpenCAP: real-time shared calendaring Apache + WebDav + IMAP gateway: shared web folders.
You could use subversion with IMAP gateway capabilities to provide a common storage.
I would also like to see an indexing engine like Lucene which can be extended to index multiple sources and types.
Now throw a web front end for user and a single way to configure all the integrated components and you can replace Exchange and/or Notes.
I'd personally like to see the admin and user frontends done in J2EE on JBoss so that you would have a sort of development platform (like Outlook + Exchange is) that businesses would be really keen to jump on. If you know anything about JBoss, think of MBean's providing gateway services from the backend servers and then providing abstracted and federated API level access to them via CORBA, SOAP , RMI, JMS, etc.
If OpenCAP is as good as Sendmail, JBoss, OpenLDAP and Cyrus, then my proposal should be scalable enough for the largest enterprise. It would also have the integration, security, developement and integration potential to attract the largest of corporate messaging users. The users who didn't need these, high-end features would just get a great messaging system that would grow with their organization.
From the design documents listed on their site, this doesn't look like much on the server side. They're going to 'jerry-rig' the asynchronous shared calendaring hack that Bynari uses. This is still not the shared calendaring that exchange provides.
These guys should be supporting and helping http://www.opencap.org, which is implementing the IETF draft for real-time shared calendaring. What they are doing is pushing static free-busy files to an FTP server then using a Calendar folder in the IMAP server for storage.
This does not enable real-time calendaring. From what I can tell, they aren't writing anything for the server-side, just configuring known packages. I can understand that their goals and time restrictions may mean that the methodology they are using for calendaring is the best they can do right now. In fact I believe this is the case, since you would pretty much have had to come across the CAP protocols doing the research that would lead you to the solution they've chosen.
I think this is a great project, and I hope they write some nice server admin tools, but this is not the 'Exchange Killer' that everyone seems to be touting it as. It is a nice start.
If you want an 'Exchange Killer', help out http://www.opencap.org. This guy has the right design (LDAP and SASL support) that will allow it to integrate with Cyrus IMAP and OpenLDAP. Since most of the OpenSource calendaring client projects (Evolution, Mozilla, etc) use libical, it should be relatively small amounts of work to make sure they work with OpenCAP, once it's ready.
BTW, Evolutions history with LDAP support has completely sucked. I noticed the last release had some work done on LDAP, but it had a ways to go last time I tried it. I want the ability to add addresses to the LDAP address book from Evolution (assuming the LDAP server has the correct ACL's).
Did any of the offspring or egg casings have Jesus' face on them?
tomorrow's headline: "Catholic's build shrine around aquarium"?
Cracks me up, I lived down the road from the building in Clearwater, Fl, when the "image" appeared due to stains on the windows. Some org bought the building and turned it into a tourist attraction, used to be a car dealership.
Did anyone else catch how akwardly showhorned in the Keith Richards quotes were?
It seemed like the editor felt compelled that Keith must be quoted at least once per page.
page 2.
Keith, for his part, just shakes his head: "It's a mom-and-pop operation," he laughs. "Mick is the mom, and I'm the pop, and then we have these offspring that need feeding."
Perhaps Keith sums it up best: "With our business, who really knows what's what. You go and look at Lake Superior, and you say, 'Look at all that water, and that's just the top!' "
I'd go on, but they're much funnier in context, so go read the article.
I don't know anything about Act! or how you were planning on using it with or without Java. I also can't really comment on a CRM system for Mac.
As far as JClass and an IDE go. Take your pick. I personally prefer Intellij's IDEA. You could use VIM, WebSphere Studio or NetBeans if you want. The JClass stuff is pure JavaBeans, which means you get to do drag and drop programming in any IDE's GUI builder.
Since neither IntelliJ or VIM have GUI designer's it looks like you prolly want NetBeans or JBuilder.(IntelliJ's beta releases also require JDK 1.4, so that may not work on Mac for a while.) I personally don't like the way NetBeans works, but if your looking for a cheap solution that will allow you to use JClass in a GUI designer it's the way to go.
Quite frankly, you don't sound incredibly knowledgable about developing Java solutions. Don't take that as an insult, just an observation since you left out a lot of information pertinent to your question. Do some more research using Google next time. Most of your questions can be answered if you better understand your problem.
You can use JClass in anything you want. Import the Jar's, make sure they're on the classpath, then write the code by hand that accesses the classes and methods in your own code. The fact that they're JavaBeans allows the GUI designer to automagically load up the properties and provide you with a visual way of laying out the components and hooking them up together. Read more about JavaBeans if your interested in this. You should be writing your own JavaBeans to speed your internal development. BTW, XDoclet now supports JavaBeans, so you can generate all the extraneous classes required by IDE's from the actual Beans source code. It's pretty slick.
Stay away from Powerbuilder. I'm currently developing a J2EE solution in a Powerbuilder shop. It's a nice self-contained environment, but it doesn't integrate well with others. I have no personal experience try to do this, but the other developers on this project have been writing Powerbuilder apps around here for the past 8 years. If you don't think you'll ever have to integrate your powerbuilder apps with anything else, it's a fast and easy solution. It's also pretty powerful for data entry and reporting. Just keep in mind that after 8 years of Powerbuilder, these guys chose J2EE.
That's what the Open Source Java community is trying to do. Check out Argo UML, it generates code from the UML diagrams, which is not that original, but it's pretty good, and open source. One of the main reasons the Java community is moving towards this concept is the reflection and introspection capabilities in Java, combined with the BECL project at Jakarta we can hand craft.class files if we want.
The frameworks like J2EE and Struts are implementing common patterns, aleviating the tedious coding and allowing us to focus more on design and architecture. Since these frameworks are well defined we have code generation tool like XDoclet and Middlegen that handle the needs of the framework while we only write the business logic.
Java looks pretty big with all the acronyms you'll find on Sun's site, but since the tools started to develop, most of the work is reduced to design, architecture and coding business logic. When I use a J2EE application server like JBoss I don't have to deal with setting up and tearing down database pool connections. JBoss provides my Enterprise Java Beans with this. Threading is handled by the server as well as persistence and synchronization with the database. Because these things are well defined and allow you to integrate hand coded stuff if you need more flexibility I am freed from solving the same problems that people have solved 15 times before. I can also migrate to a new application and be pretty certain that I'll be able to seperate the core logic from the system maintainence and utility code that any app would need.
It's not perfect YET, nor do we have the whole UML to ASM and back thing, but with gjc (java gcc front end) and the classpath project we're getting there.
You should see the reuse too. The well defined APIs and frameworks make integrating other people's code easy, and the OOPness of java allows everything to act as a library. Just look at any established open source Java project and you'll see they've built of many of the other projects out there.
Granted I'm a bit of a fanatic, I've been doing both open source and Java for about 6 years, but I've yet to see any development system that had this much promise and consistently delivered. Check it out, you won't be sorry.
You can find these projects at Sourceforge or jakarta.apache.org and xml.apache.org.
The design document makes no mention of CAP. The method for doing calendaring that is described is by using IMAP Calendar folders and posting client generated Free/Busy schedules to an FTP server, a la JiCal
The problem with this is that there is no way to schedule resources and the calendaring is still asynchronous. Scheduling resources and real-time free-busy information are two main reasons people choose Exchange or Notes over other solutions.
These guys should team up with the libical developers that are doing a calendar server. Evolution and Mozilla should both be able to plug in to that.
It seems the main reason that they are doing things this way is that Bynari's plugin will work with this schema. Quite frankly, I don't see what server development they are doing beyond a possible administration tool and documenting the configuration of existing products.
It looks like most of the development will be going into the client.
Here's to waiting for a real open source calendaring solution. Sorry to be playing the 'Stark Fist of Reality' today, I got real excited till I read the design doc.
A couple of people have already mentioned the Jakarta project and cactus in particular.
I'd highly recommend picking the book: Java Tools for eXtreme Programming
This is a great reference for all of the tools being mentioned and shows you how to integrate them into the development cycle if your using Java. You should be able to write the functional tests if your app is not written in Java.
As an aside, if your not developing these apps in Java, you really should look at using Tomcat, XDoclet and Struts for simple DB frontends, and then move to EJBs with JBoss, Jetty or Tomcat, Struts and XDoclet. If your lazy and don't want to write a lot of code, you'll love these tools. Reuse is high in Java, and the code generation tools like XDoclet take away most of the pain of using frameworks like EJB and Struts. Besides JSP taglibs allow me to have good looking pages made pretty by people who care about the differences between browsers for CSS, DHTML and what not.
IIRC, ORBit isn't a real CORBA orb in that it does it's own method of authentication and deviates from the Open Group Standards in other ways. I've always gotten the impression that the purpose of ORBit was to provide GNOME with a component messaging architecture rather than actual CORBA capabilities.
You'd really want an abstraction to which you could write your PHP code that would deal with any CORBA x.x complient ORB, then you could have modules for each ORB, like the way database stuff is abstracted in JDBC or DBD. This is one of the reasons I think enterprise apps shouldn't be written in PHP or PERL. Java provides a really good framework for these sorts of services. There are Java bindings for a lot of ORBs, RDBMs, LDAP servers, that are part of an abstraction and allows you to write code that can utilize any driver that is written for the abstraction.
That's right, if your in the good ol USA, you get $500 per each violation in civil penalities after the FCC gets it's fine. Junkbusters.org has info on this and links to the complaint pages and contact info at the FCC.
eFax.com Just got fined $24Million for doing this. It was on/. last month. Do a search in the article archive next time before wasting time posting.
FreeRadius plus OpenLDAP or PostgreSQL
on
Radius w/ MySQL?
·
· Score: 4, Informative
FreeRadius seems to be able to deal with datasource changes better than the GNU Radius Server. You can set up user auth info in OpenLDAP for FreeRadius and set up OpenLDAP in a Master-Slave cluster for scalability and robustness.
Postgres can also be used to store both auth and accounting info from FreeRadius and has the ability to live in a cluster for reliability purposes, I know their also working on scalability clusters, but I don't know how far along it is.
Having your user auth info in OpenLDAP will prolly get that info out faster than Postgres, but it can only be used to store auth info. It will most likely be easier to store all the data in Postgres.
Don't use MySQL if you want scalability, speed and robustness all in one package. Postgres has got much better features when it comes to this, it also has native data-types for ip addresses and such.
OpenLDAP might make your migration easier, with any new data you want to store going to Postgres.
I'd recommend thouroughly testing these setups first. Especially the clustering.
Until you can hook XUL up to Java Components I don't see it taking off in the business (corporate) world. XPCom is cool, but most corporate developers are doing Java or VB. VB components can be used in all of M$' client tools. Moz could be like an applet container on steriods, without Java powering the UI.
BlackConnect was supposed to offer a Java->XPCom bridge, but it seems really dead in the water. I'd love to just write an EJB backend or maybe frontend the EJBs with servlets or SOAP to marshall the data into the browser, move validation to the client side.
I could do my UI in XUL and have bridge code to hit the backend. Client-Server with the client management taken care of by Moz. It would be better than WebStart IMNSHO. Plus I could build off the other apps available to Moz.
This would reduce my development costs and by integrating XUL devel into IDE's like Eclipse and Dreamweaver, I could beat the socks off VB/ASP/.NET developers with a superior solution (cross-platform too!). I'm sure once the tools arrived quite a few corporate environments would look to Moz + J2EE as a competitor to traditional M$ client-server style apps.
It's almost there... just please give me Java support!!!!
So little research, so much posting, it's a shame. This is one of the best things to hit Open Source in a long time. First of all JBoss is an excellent project. These guys are making the proprietary J2EE world nervous. Why am I going to pay for Weblogic, WebSphere or iPlanet when JBoss does the same job?
Secondly, the JBoss development team is dedicated to Open Source Java solutions. Just read the mailing lists, check out Marc Fleury's response to McNealy's criticisms of Open Source J2EE at JBoss.org or check out the interview at theserverside.com.
Marc heads the JBoss Group, the purpose is to allow Open Source developers to do what they love for themselves and make a decent living. They have been doing training at standard corporate rates (~3000USD for a week of training) and consulting for companies that have decided to use JBoss in house. They also sell documentation (a la FSF, but not under and Open Document license). They created the JBoss Group to allow more people to get involved making money doing what they love, Open Source J2EE development.
Due to the success of JBoss, there are a lot of requests coming in from around the world for JBoss support, development and consulting. This is professional work at professional prices. 5000USD is nothing in the professional world. This is more akin to Microsoft Certified Solution Provider programs for independent consultants. The JBoss Group funnels contract work (support, development, training, etc) to it's members while handling the incoming requests (sales qualification, billing, etc). I don't know what kind of payoff this has for the members in terms of revenue, since that information is not publicly available.
I've looked into this program and am excited about it. I've personally been working on a JBoss development contract since the end of January this year, porting a J2EE app from a proprietary J2EE app server to JBoss. I have no affiliation with the JBoss Group, or the project, other than being on the mailing list and hanging out a lot in #jboss on irc.openprojects.net.
Quite frankly I don't know what else to say to the snide comments other than STFU, and get a clue. Especially timothy's snide 'become-a-certified-massage-therapist dept.' tag or the clueless comment at the end. Open Source Java projecs are a shining example of what Open Source can provide. Just look at ArgoUML, XDoclet, UML2EJB, Struts, Ant, Maven, Log4j, Xerces, Xalan, Middlegen and a ton of others. You'll see how this is providing developers with the tools they need to develop enterprise class applications quickly with good design and solid frameworks.
I haven't seen Open Source tools sneaking into more corporate networks and development houses since Samba became popular. Everybody is integrating Open Source java tools, and those vendors that don't are being shunned by the Java development community at large. Check the forums on non-Open Source dev sites or vendor sites for proof.
The JBoss Team and Marc Fleury should be held in the same regard as the Apache Group, Larry Wall and most of the other famous names from the larger projects. I'm saying this out of respect from my experiences professionaly and personally with this project. Of course it seems that Slashdot and many in the Open Source world treat the Open Source Java community as some red-headed step-child. Well, we're putting up, so get your facts straight and take a look. You might like what you see.
Sorry for the spelling errors... I'm in a hurry.
Lance Bass might be good for NASA.
on
Space News Roundup
·
· Score: 3, Interesting
As much as I dislike N'Sync or the majority of teen pop culture, this could be really good for NASA. Think about it, he's getting corporate sponsers, this will garauntee lots of promotions for his trip. He'll be on MTV and various ABC^H^H^HDisney shows talking about this to teeny boppers all over the country. He could get kids at least thinking about space, even if it is superficial. The buzz should help NASA with PR involving the voting public to some extent.
Of course I'll be simmering with jealousy and choking on the cheapening of the Space Industry to accomodate this kid, but if it helps NASA, I can deal with it.
First of all... where'd your sense of humor go? Look at Ransom's history and you'll see the numerous faux pas he's made. Caldera was always trying to be another proprietary Unix, it's only when the market beat it into his thick skull that that wouldn't fly, has he changed his tune.
In the beginning some of this was OK, it made Caldera a more polished Linux distro. I had a lot of good to say about the Caldera 1.0 beta back in '95. But he always went too far, it was pretty obvious that he saw the only way to be successful was to copy the old proprietary Unix model. The same model that handed M$ a lot of market share on a silver platter.
Contrast RedHat who has really pioneered the service and support style model that most in the Open Source community agree with. While Caldera prolly has done more to build a Linux channel for VARs, they've gone about it wrong and have built it around SCO's old model instead of getting the VARs to look at a different focus (service, support rather than product points). Ransom has essentially let dinosaurs hang on to their dying model, not doing them any favors, since IBM and M$ are going to come eat their collective lunches over the next 10 years or so.
I think you may be the one who needs to read up more on Caldera's history and especially Ransom's. BTW, I never said he was over Caldera, just that his original intent as far as getting involved with Linux was creating his own version of Sun, HP, DEC, SGI.
The projects like li18nux have been necessary to achieve that goal. Ever seen AIX error codes? Even for command line stuff, they are available in different languages. Like I said before, some of this was good, and necessary to make Linux competitive with the Unix's of old, but his intentions have always been a bit transparent and something I've never thought were wise.
C'mon, everyone knows Ransom Love never gave two hoots about Linux, he just wanted to own UNIX ever since his days at Novell when it got the cold shoulder and the shove out the door. Love's always had serious envy over SGI and SUN. Too bad for him, the days of super high margins on proprietary Unix boxen are gone.
And now integrate Zope's searching with the cyrus message store and make those documents available in public shared folders as well. Not to mention revision control of said documents.
All of the features can be done seperatly with various bits and pieces of open source software, but they rarely integrate together seemlessly, especially without some inelegant hack on top. Plus, the more you add stuff like this, the more languages and coding styles you wind up supporting just to get it to work.
This is why M$ is so successful, it integrates and fufills 80% of users needs, even if it is crap. The users don't care about security or elegance of design, they just blame the poor admin if it doesn't work all the time.
Precompile your JSPs in Ant 1.5 Then when you deploy it's will be faster than PHP cause there will be no interpretation (other than normal JVM) or compiling. If it's still too slow for you look at GJC (Java frontend for gcc) and see if you can get the whole app server to compile to native code, I actually had a gcc developer tell me this should work now... haven't tried it though so YMMV.
Also remember that developer time is way more expensive than hardware.
That page is completely outdated. The part about the calendar server that is. When I first found it I started searching all over for more info. The libical mailing list turned up some stuff, but apparently nothing has been done with it in about 6 months.
I did see new talk on the mailing list a month or so ago about another effort to try and do a CAP server finally.
BTW, ftp and webdav support aren't good enough. So everyone saying that mozilla does calendaring needs to get more info. It's not shared calendaring a la Exchange or Notes until you have a server that talks CAP.
Everything else is proprietary or asynchronous and doesn't support shared resources (conference rooms, etc).
I've been trying to do this for a couple of years. I wrote the Exchange Server Replacement HOWTO back in '99 when it looked like this might be possible very soon.
Essentially I talked about how to get IMAP/POP3/SMTP with a global Address Book and authentication and user accounts via LDAP. I've been watching this space with a lot of interest since then. The lack of updates to the HOWTO should give you some idea of what's changed, not much.
As far as calendaring goes, here's the skinny: CAP is the current IETF draft, and has been for some time, although when it will be finalized is anybody's guess. Why aren't there any shared calendaring servers? Cause there's no shared calendaring standard. You can get asynchronous calendaring in IMAP by having a decent IMAP client and using a Calendar folder, but that's hardly as feature rich as Outlook/Exchange. libical has kept up with the draft but has no server process. It's used in Evolution and the Mozilla Calendar client. So we have calendaring on the client side, but nothing on the server side. From what I've been able to discern, nobody wants to write a CAP based server till CAP is finalized, since it's gone through too many changes during the drafting process already.
The other problem is the outlook clients. The way Bynari and OpenMail (Contact) have gotten around the proprietary Exchange RPC call stuff, is to write a MAPI driver for Outlook that intercepts the client calls and sends them to the server in whatever proprietary method they might have. Integrating Outlook clients will either require a server side project on the level of Samba or a client side MAPI replacement that uses CAP, unless M$ has a change of heart and decides to support it.
In order to replace the functionality of Exchange you would need, a Calendar Server (none exists in the Open Source world), a searchable document share (WebDav on Apache can't index M$Office documents AFAIK), searchable email w/ public folders and mailing lists (Cyrus + majordomo or Sympa could feasibly work), a global address book (OpenLDAP).
Now,the real kicker, it has to all be integrated, single point of management and have a web interface for users to boot. There are a million and one PHP/Perl based web interfaces to one piece of this or another. However, trying to integrate all of this is impossible. Why?
For starters, everyone seems to want to do LAMP, as if these apps all live alone and users want to log into a seperate web interface for each function then cut and paste data between web pages and not be able to search everything as one data repository, if they can search at all.
LDAP has been available for years, and the guys at OpenLDAP have been there to solve a lot of these problems for years. Quit using an RDBMS for everything, for data that applications should share, use LDAP, stuff like authentication and application user information. LDAP has seemingly been ignored by a lot of open source programmers. Evolution's LDAP support has flat out been broken, everytime I've tried it. Mozilla's works but lacks some functionality. Granted LDAP takes about as much knowledge as learning an RDBMS to understand, but ther are currently about 3 decent LDAP management tools (lape, Directory Administrator and GQ). With LDAP you can essentially have a database schema that all apps can program to, cause it's standardized (inetOrgPerson, etc.)
Other apps seem to be developed without a thought to integrating with other apps. I tried to integrate Sympa, OpenCA, cyrus, sendmail and OpenLDAP with a custom web front end about a year ago. I paid the salaries of myself and 2 other developers for about 8 months, trying to do this. It was a failure, especially in the cases of the Perl pieces. The CPAN Perl libraries didn't do LDAPv3 extensions, isolating code in most of these projects to use a different front end was hopeless and providing an interface to manage the configuration files for the servers was a lot of work. We got about 80% done before I sold the company (and codebase). We had originally planned to GPL our work then sell support and customization, with a calendaring solution and MAPI driver for outlook in the 2.0 feature set.
Most of the frustration we had and was due to using other people's code that was not extensible or modularized. If I had to do it over again, I'd do it in Java on JBoss (esp considering the BEEP servlets JSR for CAP and the great LDAP support via JNDI).
I don't think that developer's of various open source projects need to have some overreaching design group (a la GNOME or KDE) to implement these projects with integration in mind. There are plenty of standards already out there. It just takes some good design and up front research (something I've done a lot of) and thinking about how other developers and users might want to use this stuff for their projects.
Now, I don't want to sound like I'm whining about my own failures, I should have made sure we had enough capital to do it all from scratch. I'm more concerned about our ability to compete with the Exchange servers and Lotus Notes of the world and have a stable, customizable platform that we own. Quit rewriting the same stuff over and over and build new stuff... innovate, be creative, push the industry forward.
There is a glimmer of hope, the Open Source Java community is doing fantastic stuff. I've never seen more modularization, code reuse, integration and faster development in any environment or community. JBoss really takes the lead, the feature list is amazing and I've used it in several corporate environments where it beat out commercial J2EE app servers. JBoss pulls from Ant, XDoclet, Jetty, Tomcat, JacORB, Axis, HyperSonic SQL and a bunch of other projects. Struts and the Java commons and taglib projects at Jakarta are another example of really cool work.
The point is, it all works together. End users don't care if you wrote it in Perl, PHP, Python, C or Java... Just that it makes their lives easier, if we want Open Source to get more places we have to make sure we can deliver on this. Considering most of us make a living programming, supporting or administering networked systems, which would you rather have, propietary crap or really good open source stuff? So next time your designing that project, or writing some more code think about how you can make integration easier. Documentation helps too... we shouldn't have to know fifteen languages and countless codebases to get stuff working together. Most of us specialize in a couple of things.
Well, that's been my experience and is currently my struggle, so hope you get something out of this... BTW, I'd loved to be proved wrong on any pessimism I may currently have.
Check out the mailing list archives at http://www.openldap.org. This is what LDAP was meant for, among other things. After a couple of minutes searching the openldap-software list I saw people trying to do 3 things with OpenLDAP on OSX.
1) run it. Used to have problems with replication (slurpd) and multithreading.But that was a few months ago.
2) Use it for user management like NIS. Essentially using nsswitch_ldap on OSX. Some success it looks like.
3) Use it for shared address book stuff. Working fine.
LDAP is awesome, think about a relational database where the table layout for common data is already specified for you. i.e. storing a user in a database where the table schema is the same, no matter which database you use.
This is why all the major mail clients support any LDAP server as an address book. The schema for an entry in the address book is specified, but can be expanded. Essentially you have entries in the server that are of the inetPerson object type, an entry can have multiple object types and object types can inherit from other object types. Think of an object type as a table definition in a database. You can search by object types or by attribute values (Objects are made up of defined attributes: inetPerson is an object type, email is an attribute of inetPerson).
Essentially if you write an app that knows how to deal with data stored in an inetPerson structure, it will be able to integrate with any other app that can do the same.
LDAP will not replace a generic relational database, nor is it meant to. It's optimized for reads and has a hierchical layout. You can have a SQL backend if you want, but I wouldn't do this unless I needed a gateway to a legacy database.
People should be moving data out of the database and into LDAP servers where appropriate. LDAP is the basis for Directory Services like Active Directory and Novell's Directory Services (LDAP is a gateway for Novell actually, complicated relationship).
So, essentially, use LDAP, it's a good idea. The OpenLDAP tools aren't the best and it can be a bit of a pain to set up, check out Directory Administrator and GQ (both GTK apps) to manage OpenLDAP.
Slashdot Mirror
I think I'm going to stop flying altogether if I have to get checked by bees.
What happens if you swat one of them? They try and charge you with killing a federal officer if you kill a police dog, so what about the bomb-sniffing bees? Would I find myself in the federal pen for smashing a bee?
On a more serious note, what if the bees all swarm over the bomb-disposal equipment instead of the landmines? The article says that they are just looking for DNT particles, in the parts per trillion range, so wouldn't this be present on the bomb-disposal equipment?
There's other features that this type of collection of software would lack compared to MS Exchange. There's things like the addressing support -- Exchange isn't limited to SMTP addressing, as it can handle groupwise addressing, ccmail addressing, X400 addressing (which it uses natively), or virtually any other addressing format with an appropriate plugin. While this isn't critical for single site installations, it makes multisite installations easier because SMTP addressing isn't tied to DNS. There are ways to do this with straight SMTP, but they are fairly complex.
You can do this with Sendmail. That's one of the reasons I still support Sendmail rather than some of the 'easier to maintain' MTA's. Sendmail is very versital WRT handling non-SMTP systems. But personally I can't think of any mail non-SMTP mail systems that don't include an SMTP gateway still.
Directory replication/address book: Exchange makes a copy of the directory of any connected "sites". This means they're always available in the global address list, and trying to send mail to a non-existant account instantly returns an error, even if the remote 'site' server is down.
OpenLDAP has slurpd which is an LDAP standard method of replicating directories. This feature achieves the same functionality.
"Single Instance Store": If you send a 3MB attachment to 100 people on an Exchange server, you don't consume 300MB, you consume little more than 3MB. Most MTAs can't handle multidelivery like this, and instead send an individual copy to each recipient. With ACLs and hard links, and a yet another mailbox format (separating headers and message body), you might be able to do it strictly with the file system. Lacking all of those options, the only other real alternative is to do it in a database like Exchange.
Cyrus IMAP does this. It's a function of the MDA, not the MTA.
Plugins, etc: With Exchange, you can write plug-ins and addons that interoperate with all parts of the Exchange system. Using all these separate packages, each with a different configuration and method of doing things may mean you have to make several different plugins each with a different API and language preference. If I want to plug in a foreign mail system, things get much worse. Now, I have to write some kind of gateway, and try to encapsulate the foreign addressing system into SMTP addresses and convert the messages to MIME (which would have to be done anyway). Then, I've got to write some kind of gateway for LDAP, so the foreign users show up in the directory, and read the directory, and do the reverse for the foreign system. Now, before you try to tell me that no one uses these types of systems anymore, keep in mind that a foreign system could be a fax system, X.400, voicemail or virtually anything else.
The only place I think you have a point here is the configuration mechanisms. I've long though that most of the server daemons should provide a CORBA interface to server configs, so that you could manage them on the fly and do so through a more common API. Sendmail has the interface for the foriegn system conversions, and Cyrus has an interface as well, it all depends on where the interface with the foriegn system. Quite frankly though, I'm not interested in supporting systems that don't conform to IETF standards. That's how the internet works and has created the innovations we've seen thus far. Proprietary standards for network traffic have lost. I feel perfectly comfortable telling people to go get standards compliant if they want to talk to me over the Internet. I doubt Exchange will continue to add support for weird legacy systems it doesn't support already. Most of the legacy support you mention was added when Exchange was new and had to compete and integrate with these systems. I do however think it is important to write conversion tools that allow for easy migration from non-standards compliant systems.
Now, there are quite a few things that would be nice about what they've already decided on doing. For example, there's no single database to get corrupted in their system. And seeing how I've had to deal with a corrupted Exchange database twice in the three years we've been running Exchange, and both times it was PAINFUL to recover. A single corrupt page in an Exchange database makes it impossible to back up the database, and if the corruption is in the wrong place, the repair utilities can make things worse. So, storing stuff in the file system directly is basically a good thing, although it has drawbacks, as I mentioned above.
Cyrus and OpenCap both use Berkley DB4, which has proven itself time and again. I feel comfortable sleeping at night knowing my data is in that format and I have good backups. That's the beauty of this system. It's a number of different projects, yet they all talk together using IETF standards. They reuse common pieces to achieve their specific needs and this makes it easier to understand all of the apps invloved once you understand one of them.
Since none of the legacy systems you mentioned are entrenched like say SMB is in file and print services, I don't see any reason to waste time supporting them. The system I outlined would use the following Open Standards:
SMTP
IMAP/POP3
SIEVE (server side email filtering: IETF)
SASL (authentication and authorization: IETF)
LDAP
LMTP (local mail transport protocol: IETF)
NNTP
CORBA (OMG)
SOAP (W3C?)
WEBDAV (W3C)
CAP/iCal/iMip/iTip (IETF Calendaring protocols)
SIP (instant messaging/voice over ip/voicemail: IETF)
This could be provided using the Vocal project and Jabber projects.
The difference would be that this project would require people to conform to Open Standards, which is why we have the Internet today. There is no compelling reason for widely used messaging systems to invent their own protocols at the expense of becoming and island. Those who invested in proprietary messaging systems will be forced to upgrade at some point anyway to continue talking to the rest of the world.
Remember, on the Internet the IETF is the law.
I have read about it, twice. I've also read about a lot of other systems, this particular subject has been a bit of a passion for me.
The non-legacy support is via WebDav... essentially the same thing as FTP just over HTTP. They are not using CAP anywhere.
They are not using LDAP everywhere, either. They are storing the free/busy lists on the filesystem via WebDav or FTP, not that this info should be stored in LDAP. They are storing the user account info and the address book info in LDAP, which is as it should be. OpenCAP is storing the calendar data in a db format (looks like berkley db currently) with LDAP support for users.
You've missed the point of my post. It's soley about the calendaring. I think you'll find that I agree very much with their choice of Cyrus and OpenLDAP. I also find the reason for their choices for a "quick and dirty, works with today's client's" acceptable for the interim. As I said, "It's a nice start.".
What it is not, is an "Exchange Killer", nor will it be till it supports CAP with a design like that of OpenCAP. Essentially you need to integrate:
an MTA: preferably Sendmail, due to extensive LDAP and TLS support
Cyrus IMAP: for POP3/IMAP/NNTP gateway, cyrus uses SASL and LDAP allowing integration
OpenLDAP: user accounts, address book, sendmail routing info, alias lists, etc.
OpenCAP: real-time shared calendaring
Apache + WebDav + IMAP gateway: shared web folders.
You could use subversion with IMAP gateway capabilities to provide a common storage.
I would also like to see an indexing engine like Lucene which can be extended to index multiple sources and types.
Now throw a web front end for user and a single way to configure all the integrated components and you can replace Exchange and/or Notes.
I'd personally like to see the admin and user frontends done in J2EE on JBoss so that you would have a sort of development platform (like Outlook + Exchange is) that businesses would be really keen to jump on. If you know anything about JBoss, think of MBean's providing gateway services from the backend servers and then providing abstracted and federated API level access to them via CORBA, SOAP , RMI, JMS, etc.
If OpenCAP is as good as Sendmail, JBoss, OpenLDAP and Cyrus, then my proposal should be scalable enough for the largest enterprise. It would also have the integration, security, developement and integration potential to attract the largest of corporate messaging users. The users who didn't need these, high-end features would just get a great messaging system that would grow with their organization.
From the design documents listed on their site, this doesn't look like much on the server side. They're going to 'jerry-rig' the asynchronous shared calendaring hack that Bynari uses. This is still not the shared calendaring that exchange provides.
These guys should be supporting and helping http://www.opencap.org, which is implementing the IETF draft for real-time shared calendaring. What they are doing is pushing static free-busy files to an FTP server then using a Calendar folder in the IMAP server for storage.
This does not enable real-time calendaring. From what I can tell, they aren't writing anything for the server-side, just configuring known packages. I can understand that their goals and time restrictions may mean that the methodology they are using for calendaring is the best they can do right now. In fact I believe this is the case, since you would pretty much have had to come across the CAP protocols doing the research that would lead you to the solution they've chosen.
I think this is a great project, and I hope they write some nice server admin tools, but this is not the 'Exchange Killer' that everyone seems to be touting it as. It is a nice start.
If you want an 'Exchange Killer', help out http://www.opencap.org. This guy has the right design (LDAP and SASL support) that will allow it to integrate with Cyrus IMAP and OpenLDAP. Since most of the OpenSource calendaring client projects (Evolution, Mozilla, etc) use libical, it should be relatively small amounts of work to make sure they work with OpenCAP, once it's ready.
BTW, Evolutions history with LDAP support has completely sucked. I noticed the last release had some work done on LDAP, but it had a ways to go last time I tried it. I want the ability to add addresses to the LDAP address book from Evolution (assuming the LDAP server has the correct ACL's).
Did any of the offspring or egg casings have Jesus' face on them?
tomorrow's headline: "Catholic's build shrine around aquarium"?
Cracks me up, I lived down the road from the building in Clearwater, Fl, when the "image" appeared due to stains on the windows. Some org bought the building and turned it into a tourist attraction, used to be a car dealership.
page 2.
Keith, for his part, just shakes his head: "It's a mom-and-pop operation," he laughs. "Mick is the mom, and I'm the pop, and then we have these offspring that need feeding."
Perhaps Keith sums it up best: "With our business, who really knows what's what. You go and look at Lake Superior, and you say, 'Look at all that water, and that's just the top!' "
I'd go on, but they're much funnier in context, so go read the article.
I don't know anything about Act! or how you were planning on using it with or without Java. I also can't really comment on a CRM system for Mac.
As far as JClass and an IDE go. Take your pick. I personally prefer Intellij's IDEA. You could use VIM, WebSphere Studio or NetBeans if you want. The JClass stuff is pure JavaBeans, which means you get to do drag and drop programming in any IDE's GUI builder.
Since neither IntelliJ or VIM have GUI designer's it looks like you prolly want NetBeans or JBuilder.(IntelliJ's beta releases also require JDK 1.4, so that may not work on Mac for a while.)
I personally don't like the way NetBeans works, but if your looking for a cheap solution that will allow you to use JClass in a GUI designer it's the way to go.
Quite frankly, you don't sound incredibly knowledgable about developing Java solutions. Don't take that as an insult, just an observation since you left out a lot of information pertinent to your question. Do some more research using Google next time. Most of your questions can be answered if you better understand your problem.
You can use JClass in anything you want. Import the Jar's, make sure they're on the classpath, then write the code by hand that accesses the classes and methods in your own code. The fact that they're JavaBeans allows the GUI designer to automagically load up the properties and provide you with a visual way of laying out the components and hooking them up together. Read more about JavaBeans if your interested in this. You should be writing your own JavaBeans to speed your internal development. BTW, XDoclet now supports JavaBeans, so you can generate all the extraneous classes required by IDE's from the actual Beans source code. It's pretty slick.
Stay away from Powerbuilder. I'm currently developing a J2EE solution in a Powerbuilder shop. It's a nice self-contained environment, but it doesn't integrate well with others. I have no personal experience try to do this, but the other developers on this project have been writing Powerbuilder apps around here for the past 8 years. If you don't think you'll ever have to integrate your powerbuilder apps with anything else, it's a fast and easy solution. It's also pretty powerful for data entry and reporting. Just keep in mind that after 8 years of Powerbuilder, these guys chose J2EE.
Good Luck
That's what the Open Source Java community is trying to do. .class files if we want.
Check out Argo UML, it generates code from the UML diagrams, which is not that original, but it's pretty good, and open source.
One of the main reasons the Java community is moving towards this concept is the reflection and introspection capabilities in Java, combined with the BECL project at Jakarta we can hand craft
The frameworks like J2EE and Struts are implementing common patterns, aleviating the tedious coding and allowing us to focus more on design and architecture. Since these frameworks are well defined we have code generation tool like XDoclet and Middlegen that handle the needs of the framework while we only write the business logic.
Java looks pretty big with all the acronyms you'll find on Sun's site, but since the tools started to develop, most of the work is reduced to design, architecture and coding business logic. When I use a J2EE application server like JBoss I don't have to deal with setting up and tearing down database pool connections. JBoss provides my Enterprise Java Beans with this. Threading is handled by the server as well as persistence and synchronization with the database. Because these things are well defined and allow you to integrate hand coded stuff if you need more flexibility I am freed from solving the same problems that people have solved 15 times before. I can also migrate to a new application and be pretty certain that I'll be able to seperate the core logic from the system maintainence and utility code that any app would need.
It's not perfect YET, nor do we have the whole UML to ASM and back thing, but with gjc (java gcc front end) and the classpath project we're getting there.
You should see the reuse too. The well defined APIs and frameworks make integrating other people's code easy, and the OOPness of java allows everything to act as a library. Just look at any established open source Java project and you'll see they've built of many of the other projects out there.
Granted I'm a bit of a fanatic, I've been doing both open source and Java for about 6 years, but I've yet to see any development system that had this much promise and consistently delivered. Check it out, you won't be sorry.
You can find these projects at Sourceforge or jakarta.apache.org and xml.apache.org.
The design document makes no mention of CAP. The method for doing calendaring that is described is by using IMAP Calendar folders and posting client generated Free/Busy schedules to an FTP server, a la JiCal
The problem with this is that there is no way to schedule resources and the calendaring is still asynchronous. Scheduling resources and real-time free-busy information are two main reasons people choose Exchange or Notes over other solutions.
These guys should team up with the libical developers that are doing a calendar server. Evolution and Mozilla should both be able to plug in to that.
It seems the main reason that they are doing things this way is that Bynari's plugin will work with this schema. Quite frankly, I don't see what server development they are doing beyond a possible administration tool and documenting the configuration of existing products.
It looks like most of the development will be going into the client.
Here's to waiting for a real open source calendaring solution.
Sorry to be playing the 'Stark Fist of Reality' today, I got real excited till I read the design doc.
I'd highly recommend picking the book:
Java Tools for eXtreme Programming
This is a great reference for all of the tools being mentioned and shows you how to integrate them into the development cycle if your using Java. You should be able to write the functional tests if your app is not written in Java.
As an aside, if your not developing these apps in Java, you really should look at using Tomcat, XDoclet and Struts for simple DB frontends, and then move to EJBs with JBoss, Jetty or Tomcat, Struts and XDoclet. If your lazy and don't want to write a lot of code, you'll love these tools. Reuse is high in Java, and the code generation tools like XDoclet take away most of the pain of using frameworks like EJB and Struts. Besides JSP taglibs allow me to have good looking pages made pretty by people who care about the differences between browsers for CSS, DHTML and what not.
Good Luck.
IIRC, ORBit isn't a real CORBA orb in that it does it's own method of authentication and deviates from the Open Group Standards in other ways. I've always gotten the impression that the purpose of ORBit was to provide GNOME with a component messaging architecture rather than actual CORBA capabilities.
You'd really want an abstraction to which you could write your PHP code that would deal with any CORBA x.x complient ORB, then you could have modules for each ORB, like the way database stuff is abstracted in JDBC or DBD. This is one of the reasons I think enterprise apps shouldn't be written in PHP or PERL. Java provides a really good framework for these sorts of services. There are Java bindings for a lot of ORBs, RDBMs, LDAP servers, that are part of an abstraction and allows you to write code that can utilize any driver that is written for the abstraction.
But, to each his own I guess.
what are you going to do? Take a picture of your monitor?
What your raving about would require real live naked people, which is not something most slashdotters get the chance to see.
That's right, if your in the good ol USA, you get $500 per each violation in civil penalities after the FCC gets it's fine. Junkbusters.org has info on this and links to the complaint pages and contact info at the FCC.
/. last month.
eFax.com Just got fined $24Million for doing this. It was on
Do a search in the article archive next time before wasting time posting.
FreeRadius seems to be able to deal with datasource changes better than the GNU Radius Server. You can set up user auth info in OpenLDAP for FreeRadius and set up OpenLDAP in a Master-Slave cluster for scalability and robustness.
Postgres can also be used to store both auth and accounting info from FreeRadius and has the ability to live in a cluster for reliability purposes, I know their also working on scalability clusters, but I don't know how far along it is.
Having your user auth info in OpenLDAP will prolly get that info out faster than Postgres, but it can only be used to store auth info. It will most likely be easier to store all the data in Postgres.
Don't use MySQL if you want scalability, speed and robustness all in one package. Postgres has got much better features when it comes to this, it also has native data-types for ip addresses and such.
OpenLDAP might make your migration easier, with any new data you want to store going to Postgres.
I'd recommend thouroughly testing these setups first. Especially the clustering.
Actually it's not the same, it's more akin to JNI or the Java -> ActiveX bridge that Sun wrote a couple of years ago.
M$ wanted to change the language to make it incompatible, I just want Java objects exposed in XUL.
Until you can hook XUL up to Java Components I don't see it taking off in the business (corporate) world. XPCom is cool, but most corporate developers are doing Java or VB. VB components can be used in all of M$' client tools. Moz could be like an applet container on steriods, without Java powering the UI.
BlackConnect was supposed to offer a Java->XPCom bridge, but it seems really dead in the water. I'd love to just write an EJB backend or maybe frontend the EJBs with servlets or SOAP to marshall the data into the browser, move validation to the client side.
I could do my UI in XUL and have bridge code to hit the backend. Client-Server with the client management taken care of by Moz. It would be better than WebStart IMNSHO. Plus I could build off the other apps available to Moz.
This would reduce my development costs and by integrating XUL devel into IDE's like Eclipse and Dreamweaver, I could beat the socks off VB/ASP/.NET developers with a superior solution (cross-platform too!). I'm sure once the tools arrived quite a few corporate environments would look to Moz + J2EE as a competitor to traditional M$ client-server style apps.
It's almost there... just please give me Java support!!!!
So little research, so much posting, it's a shame.
This is one of the best things to hit Open Source in a long time. First of all JBoss is an excellent project. These guys are making the proprietary J2EE world nervous. Why am I going to pay for Weblogic, WebSphere or iPlanet when JBoss does the same job?
Secondly, the JBoss development team is dedicated to Open Source Java solutions. Just read the mailing lists, check out Marc Fleury's response to McNealy's criticisms of Open Source J2EE at JBoss.org or check out the interview at theserverside.com.
Marc heads the JBoss Group, the purpose is to allow Open Source developers to do what they love for themselves and make a decent living. They have been doing training at standard corporate rates (~3000USD for a week of training) and consulting for companies that have decided to use JBoss in house. They also sell documentation (a la FSF, but not under and Open Document license). They created the JBoss Group to allow more people to get involved making money doing what they love, Open Source J2EE development.
Due to the success of JBoss, there are a lot of requests coming in from around the world for JBoss support, development and consulting. This is professional work at professional prices. 5000USD is nothing in the professional world. This is more akin to Microsoft Certified Solution Provider programs for independent consultants. The JBoss Group funnels contract work (support, development, training, etc) to it's members while handling the incoming requests (sales qualification, billing, etc). I don't know what kind of payoff this has for the members in terms of revenue, since that information is not publicly available.
I've looked into this program and am excited about it. I've personally been working on a JBoss development contract since the end of January this year, porting a J2EE app from a proprietary J2EE app server to JBoss. I have no affiliation with the JBoss Group, or the project, other than being on the mailing list and hanging out a lot in #jboss on irc.openprojects.net.
Quite frankly I don't know what else to say to the snide comments other than STFU, and get a clue. Especially timothy's snide 'become-a-certified-massage-therapist dept.' tag or the clueless comment at the end. Open Source Java projecs are a shining example of what Open Source can provide. Just look at ArgoUML, XDoclet, UML2EJB, Struts, Ant, Maven, Log4j, Xerces, Xalan, Middlegen and a ton of others. You'll see how this is providing developers with the tools they need to develop enterprise class applications quickly with good design and solid frameworks.
I haven't seen Open Source tools sneaking into more corporate networks and development houses since Samba became popular. Everybody is integrating Open Source java tools, and those vendors that don't are being shunned by the Java development community at large. Check the forums on non-Open Source dev sites or vendor sites for proof.
The JBoss Team and Marc Fleury should be held in the same regard as the Apache Group, Larry Wall and most of the other famous names from the larger projects. I'm saying this out of respect from my experiences professionaly and personally with this project. Of course it seems that Slashdot and many in the Open Source world treat the Open Source Java community as some red-headed step-child. Well, we're putting up, so get your facts straight and take a look. You might like what you see.
Sorry for the spelling errors... I'm in a hurry.
As much as I dislike N'Sync or the majority of teen pop culture, this could be really good for NASA. Think about it, he's getting corporate sponsers, this will garauntee lots of promotions for his trip. He'll be on MTV and various ABC^H^H^HDisney shows talking about this to teeny boppers all over the country. He could get kids at least thinking about space, even if it is superficial. The buzz should help NASA with PR involving the voting public to some extent.
Of course I'll be simmering with jealousy and choking on the cheapening of the Space Industry to accomodate this kid, but if it helps NASA, I can deal with it.
First of all... where'd your sense of humor go?
Look at Ransom's history and you'll see the numerous faux pas he's made.
Caldera was always trying to be another proprietary Unix, it's only when the market beat it into his thick skull that that wouldn't fly, has he changed his tune.
In the beginning some of this was OK, it made Caldera a more polished Linux distro. I had a lot of good to say about the Caldera 1.0 beta back in '95. But he always went too far, it was pretty obvious that he saw the only way to be successful was to copy the old proprietary Unix model. The same model that handed M$ a lot of market share on a silver platter.
Contrast RedHat who has really pioneered the service and support style model that most in the Open Source community agree with. While Caldera prolly has done more to build a Linux channel for VARs, they've gone about it wrong and have built it around SCO's old model instead of getting the VARs to look at a different focus (service, support rather than product points). Ransom has essentially let dinosaurs hang on to their dying model, not doing them any favors, since IBM and M$ are going to come eat their collective lunches over the next 10 years or so.
I think you may be the one who needs to read up more on Caldera's history and especially Ransom's. BTW, I never said he was over Caldera, just that his original intent as far as getting involved with Linux was creating his own version of Sun, HP, DEC, SGI.
The projects like li18nux have been necessary to achieve that goal. Ever seen AIX error codes? Even for command line stuff, they are available in different languages. Like I said before, some of this was good, and necessary to make Linux competitive with the Unix's of old, but his intentions have always been a bit transparent and something I've never thought were wise.
Who bought Who?
C'mon, everyone knows Ransom Love never gave two hoots about Linux, he just wanted to own UNIX ever since his days at Novell when it got the cold shoulder and the shove out the door. Love's always had serious envy over SGI and SUN. Too bad for him, the days of super high margins on proprietary Unix boxen are gone.
No time for Love...
And now integrate Zope's searching with the cyrus message store and make those documents available in public shared folders as well. Not to mention revision control of said documents.
All of the features can be done seperatly with various bits and pieces of open source software, but they rarely integrate together seemlessly, especially without some inelegant hack on top. Plus, the more you add stuff like this, the more languages and coding styles you wind up supporting just to get it to work.
This is why M$ is so successful, it integrates and fufills 80% of users needs, even if it is crap. The users don't care about security or elegance of design, they just blame the poor admin if it doesn't work all the time.
Precompile your JSPs in Ant 1.5
Then when you deploy it's will be faster than PHP cause there will be no interpretation (other than normal JVM) or compiling. If it's still too slow for you look at GJC (Java frontend for gcc) and see if you can get the whole app server to compile to native code, I actually had a gcc developer tell me this should work now... haven't tried it though so YMMV.
Also remember that developer time is way more expensive than hardware.
That page is completely outdated. The part about the calendar server that is. When I first found it I started searching all over for more info. The libical mailing list turned up some stuff, but apparently nothing has been done with it in about 6 months.
I did see new talk on the mailing list a month or so ago about another effort to try and do a CAP server finally.
BTW, ftp and webdav support aren't good enough. So everyone saying that mozilla does calendaring needs to get more info. It's not shared calendaring a la Exchange or Notes until you have a server that talks CAP.
Everything else is proprietary or asynchronous and doesn't support shared resources (conference rooms, etc).
Sorry to be such a stick in the mud today...
I've been trying to do this for a couple of years. I wrote the Exchange Server Replacement HOWTO back in '99 when it looked like this might be possible very soon.
Essentially I talked about how to get IMAP/POP3/SMTP with a global Address Book and authentication and user accounts via LDAP. I've been watching this space with a lot of interest since then. The lack of updates to the HOWTO should give you some idea of what's changed, not much.
As far as calendaring goes, here's the skinny: CAP is the current IETF draft, and has been for some time, although when it will be finalized is anybody's guess. Why aren't there any shared calendaring servers? Cause there's no shared calendaring standard. You can get asynchronous calendaring in IMAP by having a decent IMAP client and using a Calendar folder, but that's hardly as feature rich as Outlook/Exchange. libical has kept up with the draft but has no server process. It's used in Evolution and the Mozilla Calendar client. So we have calendaring on the client side, but nothing on the server side. From what I've been able to discern, nobody wants to write a CAP based server till CAP is finalized, since it's gone through too many changes during the drafting process already.
The other problem is the outlook clients. The way Bynari and OpenMail (Contact) have gotten around the proprietary Exchange RPC call stuff, is to write a MAPI driver for Outlook that intercepts the client calls and sends them to the server in whatever proprietary method they might have. Integrating Outlook clients will either require a server side project on the level of Samba or a client side MAPI replacement that uses CAP, unless M$ has a change of heart and decides to support it.
In order to replace the functionality of Exchange you would need, a Calendar Server (none exists in the Open Source world), a searchable document share (WebDav on Apache can't index M$Office documents AFAIK), searchable email w/ public folders and mailing lists (Cyrus + majordomo or Sympa could feasibly work), a global address book (OpenLDAP).
Now,the real kicker, it has to all be integrated, single point of management and have a web interface for users to boot. There are a million and one PHP/Perl based web interfaces to one piece of this or another. However, trying to integrate all of this is impossible. Why?
For starters, everyone seems to want to do LAMP, as if these apps all live alone and users want to log into a seperate web interface for each function then cut and paste data between web pages and not be able to search everything as one data repository, if they can search at all.
LDAP has been available for years, and the guys at OpenLDAP have been there to solve a lot of these problems for years. Quit using an RDBMS for everything, for data that applications should share, use LDAP, stuff like authentication and application user information. LDAP has seemingly been ignored by a lot of open source programmers. Evolution's LDAP support has flat out been broken, everytime I've tried it. Mozilla's works but lacks some functionality. Granted LDAP takes about as much knowledge as learning an RDBMS to understand, but ther are currently about 3 decent LDAP management tools (lape, Directory Administrator and GQ). With LDAP you can essentially have a database schema that all apps can program to, cause it's standardized (inetOrgPerson, etc.)
Other apps seem to be developed without a thought to integrating with other apps. I tried to integrate Sympa, OpenCA, cyrus, sendmail and OpenLDAP with a custom web front end about a year ago. I paid the salaries of myself and 2 other developers for about 8 months, trying to do this. It was a failure, especially in the cases of the Perl pieces. The CPAN Perl libraries didn't do LDAPv3 extensions, isolating code in most of these projects to use a different front end was hopeless and providing an interface to manage the configuration files for the servers was a lot of work. We got about 80% done before I sold the company (and codebase). We had originally planned to GPL our work then sell support and customization, with a calendaring solution and MAPI driver for outlook in the 2.0 feature set.
Most of the frustration we had and was due to using other people's code that was not extensible or modularized. If I had to do it over again, I'd do it in Java on JBoss (esp considering the BEEP servlets JSR for CAP and the great LDAP support via JNDI).
I don't think that developer's of various open source projects need to have some overreaching design group (a la GNOME or KDE) to implement these projects with integration in mind. There are plenty of standards already out there. It just takes some good design and up front research (something I've done a lot of) and thinking about how other developers and users might want to use this stuff for their projects.
Now, I don't want to sound like I'm whining about my own failures, I should have made sure we had enough capital to do it all from scratch. I'm more concerned about our ability to compete with the Exchange servers and Lotus Notes of the world and have a stable, customizable platform that we own. Quit rewriting the same stuff over and over and build new stuff... innovate, be creative, push the industry forward.
There is a glimmer of hope, the Open Source Java community is doing fantastic stuff. I've never seen more modularization, code reuse, integration and faster development in any environment or community. JBoss really takes the lead, the feature list is amazing and I've used it in several corporate environments where it beat out commercial J2EE app servers. JBoss pulls from Ant, XDoclet, Jetty, Tomcat, JacORB, Axis, HyperSonic SQL and a bunch of other projects. Struts and the Java commons and taglib projects at Jakarta are another example of really cool work.
The point is, it all works together. End users don't care if you wrote it in Perl, PHP, Python, C or Java... Just that it makes their lives easier, if we want Open Source to get more places we have to make sure we can deliver on this. Considering most of us make a living programming, supporting or administering networked systems, which would you rather have, propietary crap or really good open source stuff? So next time your designing that project, or writing some more code think about how you can make integration easier. Documentation helps too... we shouldn't have to know fifteen languages and countless codebases to get stuff working together. Most of us specialize in a couple of things.
Well, that's been my experience and is currently my struggle, so hope you get something out of this... BTW, I'd loved to be proved wrong on any pessimism I may currently have.
Check out the mailing list archives at http://www.openldap.org.
This is what LDAP was meant for, among other things.
After a couple of minutes searching the openldap-software list I saw people trying to do 3 things with OpenLDAP on OSX.
1) run it. Used to have problems with replication (slurpd) and multithreading.But that was a few months ago.
2) Use it for user management like NIS. Essentially using nsswitch_ldap on OSX. Some success it looks like.
3) Use it for shared address book stuff. Working fine.
LDAP is awesome, think about a relational database where the table layout for common data is already specified for you. i.e. storing a user in a database where the table schema is the same, no matter which database you use.
This is why all the major mail clients support any LDAP server as an address book. The schema for an entry in the address book is specified, but can be expanded. Essentially you have entries in the server that are of the inetPerson object type, an entry can have multiple object types and object types can inherit from other object types. Think of an object type as a table definition in a database. You can search by object types or by attribute values (Objects are made up of defined attributes: inetPerson is an object type, email is an attribute of inetPerson).
Essentially if you write an app that knows how to deal with data stored in an inetPerson structure, it will be able to integrate with any other app that can do the same.
LDAP will not replace a generic relational database, nor is it meant to. It's optimized for reads and has a hierchical layout. You can have a SQL backend if you want, but I wouldn't do this unless I needed a gateway to a legacy database.
People should be moving data out of the database and into LDAP servers where appropriate. LDAP is the basis for Directory Services like Active Directory and Novell's Directory Services (LDAP is a gateway for Novell actually, complicated relationship).
So, essentially, use LDAP, it's a good idea. The OpenLDAP tools aren't the best and it can be a bit of a pain to set up, check out Directory Administrator and GQ (both GTK apps) to manage OpenLDAP.
Have fun....