Keith Visco wrote:
Nick,
You need to stop asking these types of questions, or I'm going to put everyone to sleep with my answers! :-)
Now this is simply my personal opinion on remembering the events as they took place, Assaf may have a slightly different recount, but I'll try to be as concise as possible.
Well, Castor was basically, as Assaf likes to say, born out of necessity. Keep in mind that Assaf and I were both working at Exoffice (now called Intalio, Inc.). Exoffice was founded under the premise that everything we developed we would open source. This was all good and well under the dot com boom, but in order to survive after the dot com bust, Exoffice had to change it's business approach, and Intalio was born. Everything that Exoffice had created as open source, remained open, but Intalio was no longer supporting it, such as Tyrex, OpenORB, Slide, and others. The only project that remained on exolab.org was Castor, thanks to my incessant whining about it. Most of the other projects ended up at SourceForge or Apache. OK, onto the story...
Assaf actually had been working on the initial stages of Tyrex (An open source transaction manager) and what is now known as "Castor JDO". It wasn't actually called Castor then, it really didn't have a name. I ended up giving Castor its name just before we released the first public version back in December 1999. Actually, I came up with a bunch of names, and then Assaf, Ismael Ghalimi, and I voted on Castor as the right name for the product/project.
Anyway, Assaf was working on Tyrex and Castor JDO in the comforts of his nice office in Burlingame, CA. I was working from a cubicle just outside of his office. One day he yelled out that he needed something to read an XML based configuration file and turn it into a set of Java "data objects" so that he could interact with the configuration data in Java and not deal with the W3C DOM or have to write a SAX DocumentHandler. He also wanted the ability to be able to persist the data objects again as XML if changes were made to the objects. So that's really how it all began. And since one of Exoffice's goals was to make everything open source, of course this little binding framework was going to be open source too.
After doing a little research into the subject, we found the first draft of Sun's JSR 31 (later to be named JAXB). An extremely rough document describing very basic XML data binding and all based on DTDs. There was no sample implementation, no code at all at the time I started doing my initial version of Castor XML. At the time, I was working on other XML technologies (such as XSLT (eg adaptx)) and was following the W3C effort on XML Schema. Assaf and I decided to base our implementation using XML Schema instead of DTDs since we wanted to be leading edge and had assumed that eventually XML Schema would be quite popular. Given that is was clearly much more expressive than DTDs, it was really a no brainer.
So I started writing an XML Schema object model, even though XML Schema was in an early working draft state and changing frequently. I wrote the first Castor source code generator and introspector. Assaf was working on JDO mapping files and the mapping framework that eventually became what you see today in the org.exolab.castor.mapping package and the jdo / persist packages. Assaf then later added the ldap support.
Castor XML originally didn't have a mapping file. It was only default introspection and source code generation. Castor JDO consisted of mapping files, and used Castor XML to read database config files and the mapping files.
We eventually decided that the two projects should merge together. We spent many afternoons drinking coffee at a little French Cafe in Burlingame, and eating french fries for lunch, discussing things like ClassDescriptors and FieldDescriptors, FieldHandlers, and Mapping files. Quite fun and very interesting.
Well, the rest you can probably piece together.
Unfortunately some of the early design of Castor still plagues Castor today. Once you release something publically, users get very angry if there isn't a simple upgrade path. So we've maintained a lot of legacy code in Castor. Some of that really needs to be rewritten. I've done my best to add new functionality while trying to maintain as much backward compatibility as possible. I've definately broke some backward compatibility over the years and plan on doing it again. We need to add more information to the descriptor interfaces and rewrite some of the mapping framework and marshalling framework to improve the framework so that it can support more of XML Schema, and more advanced mappings...basically what the users want.
If I had endless amounts of time, Castor XML would be far better than it is today.
I'm not sure how long Castor XML will remain viable though. Currently Sun and others are working on JAXB 2.0 and it aims to cover much of what Castor provides today and a lot more. I was actually an active member early on in the JAXB 2.0 working group, but haven't been able to participate in a long time, basically ever since Intalio reduced it's engineering force my plate has been too full to participate in any external working groups. I know they have some smart people though, like Joe Fialli and Sekhar Vajjhala of Sun, Dennis Sosnoski (a one time Castor user who wrote his own framework called JiBX), and a number of other smart and talented people working on the spec.
Once it comes out, I'll need to see what it'll take for Castor to support it, but Sun will have their reference implementation out long before Castor XML catches up. There's always room for competition, but competing with something that will eventually come with the JDK is a bit difficult to do.
We'll see. Well, I think I've answered your question and then some...too much elaboration on my part. Sorry for not being concise enough.
All I can say is thank you yet again, Keith. For me this could easily wind up being one *fascinating* conversation. I really do think that you should publish this in a doc on the website for public consumption.
My favorite statement is this:
'If I had endless amounts of time, Castor XML would be far better
than it is today.'Preach on brother Keith! I couldn't have expressed it better myself!
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://geronimo.apache.org/
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
