Those who know me or who've seen me speak know that I don't pull any punches; this is a deliberate stance on my part, as I'm generally way too busy to bother with soft-shoeing around topical areas that might be sensitive to certain groups or teams. I call 'em as I see 'em, and if people don't like the results, I'm always open to being convinced otherwise. (Strong opinionation and high open-mindedness have to go hand-in-hand, if you're going to work to avoid being proven a complete idiot repeatedly in your life.)

That's why I have to give a huge shout out to the Sun build and source-repository engineers who've been working over the last half-year or so (probably longer, but I don't know for certain) to make the OpenJDK project a reality. Where they could have simply tossed the source and build state into a Subversion or CVS respository, washed their hands and said, "There, the source is out there, enjoy", they've instead slowly-and-steadily taken what was a pretty ugly setup and build process and whittled it down to a pretty dirt-simple set of instructions to get a JDK build up and running on your local machine.

If you ever took a moment to pull down the SCSL or JCL sources for JDK 1.2 or 1.3, particularly if you were on a Windows box (as I am), you probably fled screaming from the room (as I did, more than once). The old builds required out-of-date versions of Microsoft Visual C++ (5.0!), and a commercial UNIX-like toolset (MKS, and not even a version you could purchase anywhere, from what I could see). Clearly, the build process in those days was geared specifically around the environment that was existing inside of Sun, and if you weren't a Sun employee with access to those specific versions of those tools, forget it. You still had the source, but...

I pulled down the OpenJDK bits again last night (fresh SVN checkout), and I realized as I was going through the steps to rebrick the build environment that it's been getting steadily simpler and simpler. First, the build tools for Windows now need nothing more complicated than a few tools out of Cygwin and the GNU Make utility (largely because the Windows NMAKE utility is pretty weak compared to GNU's, not to mention the fact that NMAKE doesn't really exist for non-Windows platforms... the SSCLI-built version being the only exception I know). Second, the version of the Microsoft compiler needed has been upgraded to Visual Studio 2003 (not 2005, as building native apps under 2005 took a left turn, as anyone who's ever wrestled with manifests and DLLs can tell you), and a version of the DirectX9 SDK (which is a free download from MSDN). As a matter of fact, if you just want to build the various flavors of Hotspot and not the rt.jar bits from sources, you can even skip GNU make and the DirectX SDK. It's almost turnkey from there.

If you're any kind of plumbing wonk, as I aspire/desire/claim to be, this is a huge step in the right direction, and it's easy to repeat: fire up your Subversion client, point it to the OpenJDK SVN respository, pull down the trunk, and start building. Particularly fun is to build a 'debug' build of Hotspot in order to get the symbols, then build a custom Java launcher, and step through it in the debugger. And I mean, right out of your launcher and into the JDK itself. Or, drop the compiled 'debug' JVM.DLL into your JRE's bin\client or bin\server (or, as I do, create new subdirectories in the bin dir and create some custom -debugclient and -debugserver options, so you can switch back and forth as desired). Or, take the compiled 'fastdebug' build, and run it with the '-Xprintflags' option, in case you needed to be convinced that you really don't know all the -XX options that are available to you...

Kudos, Sun build team. Major, major kudos.

And yes, for those in the .NET space that were wondering, SSCLI Essentials, 2nd Ed, is under way as I write this...

It's not often that I meet another "Ted" in the world, much less in my own industry. The last one I knew (besides my great-uncle Ted, who unfortunately passed away a number of years ago) was Ted Rallis, a buddy of mine from my college days who was equal parts philosopher and contemplator-of-navel lint and computer scientist (whom I haven't seen in years, if you're out there Mr. Rallis, drop me a line).

I'd heard rumors of an evil twin brother, though. People claimed that they'd met me at other shows, and while I won't claim to remember everybody I've ever met at a conference (much as I'd like to, my memory just isn't that good), I was pretty convinced that at least a percentage of those folks claiming to have met me before were somehow mistaken. Now I'm sure of it.

While at TSSJS 2007 in Barcelona, I met Ted Goddard, the architect of ICEFaces, and damn if we don't look alike. One of his compatriots snapped a photo of the two of us, and Ted blogged it.

Oh, and by the way? If you're using JSF (which a rising number of people appear to be doing, according to the NFJS polls we take during the speaker panel), you should check out the fruit of Ted's labors. I'm no JSF expert, but people I trust tell me it's pretty good stuff....

Anyone who is deeply enmeshed in a technology feels compelled to defend that technology when any sort of "threat" (or perception of threat) appears on the horizon, and apparently Gavin is no different. Sure enough, as people (apparently in this case, myself) start to talk about approaches to persistence that don't involve Hibernate, Gavin feels compelled to point to these other technologies using inflammatory terms and a certain amount of FUD. I felt a certain responsibility to respond, since it seems that he's taking a direct shot at the db4o articles I've written and discussed before.

(By the way, it's also entirely possible that he's taking aim against ActiveRecord and Rails, which I don't consider to be an "object database" at all; if that's the case, then I apologize ahead of time for misunderstanding the intent--and the points--of the piece. But the arguments he makes seem pretty relevant to the OODBMS-vs-RDBMS discusison as well, so much so that it was a db4o employee who pointed out the blog entry to me in the first place. In any event, though, Gavin's piece raises some issues that deserve to be discussed, regardless of the context of Rails or OODBMSs.)

First of all, let me state quite clearly, the relational database needs no defense. Take whatever comparitive criteria you like, the RDBMS has been, and will, in the absence of a nearly catastrophic change to the contrary, continue to be, the choice of businesses all over the world for storing data in a format that's easily-accessed from a variety of different systems. The RDBMS clearly "owns" the corporate data center, from Fortune X's (meaning X can be just about any number you choose to put there) down through single-person shops. To shake that kind of (dare I say it?) monopoly would require a kind of technology shift on the scale of the move from the mini- and mainframe to the PC. Those kinds of shifts don't happen very often, and when they do, it's because of a huge competitive advantage.

Furthermore, I wil go on the record and say it here: neither the OODBMS nor the HODBMS (hierarchically-oriented database system, a la the "XML database") makes that kind of case. Not right now, and probably not ever. They have compelling reasons for existence, but not so strong a case that they could displace the RDBMS from the "enterprise data" throne. That said, however, since when does one tool solve all problems? They have their own raisons d'etre, and to simply say that the OODBMS or HODBMS should be ignored just because "we've always used an RDBMS" is a crime just as great.

Now, having said that, let's take a look at Gavin's points:

• "Object databases were a total failure and still are." Actually, he's right, from the perspective that the OODBMS clearly has not penetrated the corporate environment to the same degree that the RDBMS has. But, by that same token, the RDBMS, nearly a decade after its introduction, had about the same degree of success. Ask the folks who were around when Oracle 1 was released, and they'll tell you about the criticisms leveled at the RDBMS that are, in a startling replay of the past, now being applied to the OODBMS today. The first generation of anything is always crap... including O/R-Ms. Fortunately for both O/R-Ms and OODBMSs, neither is in their first generation stage anymore.
• "the systems are often not called "object databases" in today's marketing literature, but we will call them that anyway, since that is what they are." Actually, all of the OODBMS vendors are pretty ready to call themselves OODBMSs, and I have to say, Gavin, you'd know that if you talked to them for more than, say, 30 seconds, or took the time to research the subject and listen to what they had to say. The folks who don't bother calling their systems "object databases" anymore are the very folks he's defending: Oracle, DB/2, and so on. (Anybody remember "Oracle Objects"? Table + sprocs == objects? Oy, what a mess.) But don't feel too bad, Gavin, you're in good company--Chris Date himself makes this same mistake (though he at least admits that true "object" support in the database model requires features that aren't present in todays RDBMS products, not that he's a big fan of those products anyway), so at least you're in good comapny. (Again, if you're talking Rails being an "object database", total agreement, it's not even close. But in all the years I've been hanging out with Dave Thomas, Bruce Tate, Stu Halloway, Justin Gehtland, and a bunch of the other Rails advocates/evangelists/lecturers/authors, I've never heard any of them make this assertion.)
• Object-relational mapping isn't that hard, so there's no need to eliminate it. Sorry, Gavin, but the fact is, this remains, and always will remain, a point of difference between you and I, and between you and a fairly large number of developers I've spoken to over the years at conferences and consulting engagements and classes. For simple table-to-class mappings, you're right, it's a pretty simple thing. It is, however, still a "dual schema" problem, in that now you have two competing "sources of truth" that have to be reconciled to one another, the database schema, and the object model. Now, perhaps if all the projects you've ever done are projects where the developer gets to define both, then the problem doesn't appear, but if you're in an "enterprise" world where the database schema is managed by a team of DBAs and is shared across projects, you don't have the flexibility to "refactor" the schema like you can your object model. (Anyone who's ever tried to build a CORBA or DCOM system that stretches across corporate or division or department boundaries understands the problems of trying to create a domain model--or schema--that serves all groups well without sacrificing performance, elegance, or normal form.) I particularly like this statement:

  So, from this point of view, ORM is at least as good as an object database for all usecases, and handles other usecases (indeed, the common cases) which the object database approach does not.

  ... particularly since he doesn't bother to go on to describe those use cases that the ORM handles that the OODBMS does not. Examples? 'Tis very easy to make assertions, but without backing them up....
• Oh, and the comment that "If you just want to "throw some objects in the database", you'll never need to write a single mapping annotation." really sort of proves the point I try to make in the ODMG.org paper: if you just want to "throw some objects in the database", why do you bother having an RDBMS in the first place? There are DBAs that are in open revolt at the idea, particularly since you've also just conveniently left out any sort of indexing or other tuning decisions that will make the database perform at all reasonably. But, I suppose, if you're willing to argue "development speed uber alles", then sure, go ahead. Never mind the fact that an OODBMS will handle this exact situation, because that's exactly what they were made for. I repeat the statements I made in the ODMB paper: if you want persistence to just be an implementation detail, then why bother with the RDBMS in the first place? (It's not like any self-respecting DBA is going to want to take your slapdash relational schema, anyway...)
• Don't use the OODBMS because it creates a tight coupling between your code and your data storage, and the language you use today won't necessarily be around tomorrow. Um... exactly. This is, surprisingly enough, exactly the point I'm trying to make in the ODMG paper: that an OODBMS creates a tight coupling between code and data, and sometimes, that's not what you want. Nothing is a silver bullet, everything comes with a price and a consequence of using it. It's only the honest vendors that will tell you when not to use their stuff, and from experience, the db4o guys (the only ones I can concretely speak to) are the first to stand up and tell you that they aren't trying to replace the RDBMS. So why spread the FUD that they are?
• OODBMSs are trying to pull the wool over your eyes with benchmarks. So, again, rather than display his own benchmark that directly contradicts the benchmark offered by the OODBMS folks, Gavin chooses to say, "Look at all the reasons why they run faster, and look, these reasons are all clearly bogus." Which is kind of astute of him: lawyers are taught in law school that if the law isn't on your side, argue the facts, and if the facts aren't on your side, argue the law, and if neither is on your side, argue really really loudly. Toss out a benchmark of your own, Gavin, and then we can discuss the decisions you make in your benchmark and see if they're reasonable decisions to make for my own projects, so I can make an informed decision, rather than one based on your assertions and loud arguments that amount to "Duh!".
• OODBMSs are faster because they run in-process. Some do, yes. Most can run either in-proc or out-of-proc, which (gasp!) is something that RDBMSs can do, too. Or have you not noticed HSQL and Derby recently? And yes, running the RDBMS in-proc performs better than running the RDBMS out-of-proc. Running anything in-proc performs better than running out-of-proc. And yes, you're right, sometimes you don't have the option of in-proc. But in a situation where you're just "throwing objects into the database", and nobody else is connecting to this data (in other words, you can be tightly coupled to the data storage), why take that overhead if it's not necessary? Choosing an out-of-proc database because "somebody may want to get to this data someday" is YAGNI, pure and simple.
• "... the problem is that existing, mature RDBMS systems happen to not be written in Java (see Benefit #3)." Ouch. Don't let the Cloudscape developers hear you say that. Granted, HSQL is not what I'd call a "heavy-duty" RDBMS, but Gavin, not everything has to be stored in Oracle. Sometimes a lighter-weight database--MySQL, HSQL, Postgres, or even (gasp!) Access--is good enough. Or are you advocating that everybody should be using clustered J2EE servers to build their 5-user department calendar app? (Maybe it's a Seam thing, I dunno.)
• OODBMSs don't scale because they share a lot of state across concurrent threads. Any architecture that shares state across concurrent threads will have a hard time scaling, but... aren't you the guy arguing that stateful session beans are better than stateless? And how is this different from an RDBMS sharing state across concurrent threads? The transaction model isn't any different between the OODBMS and the RDBMS...
• OODBMS benchmarks suck because they measure ORM with caching turned off. As well they should, because not all ORM users can use caching. Particularly if they need to bypass the ORM for particularly sophisticated straight-up SQL queries. (Unless, of course, one subscribes to the belief that HQL or OQL is just as powerful as SQL itself, and therefore can do anything that SQL can do...) That said, it's still a fair argument, and benchmarks, if they're to be at all useful to the general community (as opposed to being just plain marketing fluff), should detail exactly how they were run so a technology investigator can re-run the benchmark on their own, see if the results match, and tune them as desired to better match their architectural constraints or opportunities.
• "Things that do more stuff are slower". Agreed... but how is this refuting the point? If an O/R-M is doing more stuff than an OODBMS, but the end result is the same from the programmer's perspective, the fact tha the O/R-M has to do more stuff shouldn't be held against it? That's like suggesting that Tonya Harding should have gotten a do-over in the Olympics because she was kinda upset about all the bad publicity.
• "Fetching hierarchical data.... there is no a priori reason why an object database should be any faster than an ORM solution for this." Absolutely! The problem is with the general approach of trying to manage the associations of the object model and the fact that the complete object graph (which doesn't have to be a hierarchy, by the way) frequently is larger than the programmer wants to pull across the wire. (Which is another great reason to look into an in-proc solution: no wires involved.) This will remain a problem--pending a perfect solution, which I believe does not exist, since the decision whether to eager- or lazy-fetch elements or associations will vary on a case-by-case basis--for both the OODBMS and the O/R-M world.

If you think that relational technology is for persisting the state of your application, you've missed the point. The value of the relational model is that it's democratic. Anyone's favorite programming language can understand sets of tuples of primitive values. Relational databases are an integration technology, not just a persistence technology. And integration is important. That's why we are stuck with them.

So... the .NET Rocks! discussion between myself and Ayende is now live on the Web, and I echo Ayende's blog post: although I have yet to hear the edited version, the real discussion was very interesting. A couple of commenters left some questions and comments on Ayende's blog, and Roy Osherove suggested that he'd like to see my responses, so...

Congratulations on the discussion. I've listened to it once and intend to listen again, mainly because I had trouble figuring out exactlly what Ted was arguing for or against!

In general, I'm against dogma of any form. In this particular debate, I'm against the idea that O/R-M can solve all your problems for you without asking, a viewpoint that's particularly widespread in the Java community and a growing one in the .NET community. O/R-M can get you some of the way there, but it's not capable of "closing the loop", per se, to completely solve all of the issues involved. Anyone who suggests that it can is either lying or trying to sell you something.

Ted really lost the plot, however, when he started advocating db4o as a good solution. I've spent a good few (too many) years in the object database space and they're just a nightmare when it comes to querying and reporting on your data. Implemeinting this sort of solution just moves the dual schema problem out to your databases.

I wasn't aware there was a "plot" that we were trying to follow. Moreover, I *do* see the OODBMS approach (of which, I am most familiar with db4o and to a lesser degree Versant, no endorsement implied) as a good solution to store objects into, particularly when compared against an O/R-M solution, for those scenarios where the stored form of the data is not a visible concern. In other words, if your application sees persistent storage as a implementation issue, and the actual format of the stored data is not intended to be visible outside of your application boundaries, then the OODBMS is a very viable solution. As to querying and reporting, the querying story is much more approachable now given db4o's "Native Queries" approach (which is supposedly being applied as the standard for a future OODBMS-wide standard), but reporting is still something of a mess, if you ask me, largely not because of anythiing intrinsic in the OODBMS space itself, but the fact that there is no standard OODBMS-based reporting tool. (Like it or hate it, Crystal Reports did a lot to solidify the presence of the relational database in the IT world.)

I recall being on the comp.databases.object newsgroup when db4o was first being designed. Its initial purpose was to provide something that would perform better than relational databases, and the guy developing it spent quite some time developing his benchmarks to prove his case. I'm suspicious of any solution designed primarily to improve on performance.

I don't know what the original intent was, but the db4o team has definitely tried to build an OODBMS that was aimed specifically at the "lighter weight" persistence scenarios, such as small devices.

I feel like Ted’s points were only applicable to the edge cases which are very few when it comes to a whole application. It also seems that Ted just thinks writing SQL is less work than good old expressive OOP.

I'm not sure which points were only applicable to the edge cases, or what those edge cases would be, but Ted certainly doesn't feel like his points are only applicable to edge cases. And honestly, Ted does sometimes think that writing SQL is less work than "good old expressive OOP", particularly in those cases where the relational database imposed on the project is not intrinsically OOP-ish. And because Ted has seen "good old expressive OOP" models that were just as badly designed as the relational schema that Ayende references in the discussion.

The other key point that was not mentioned during the vendor neutrality and portability section was that NHibernate IS optimized to a particular vendor’s database. Ted assumes that because NHibernate is database agnostics you loose all the powerful vendor specific features of the rdbms. Not True!! Look at how paging is handled; the SQL 2005 Dialect uses very vendor specific code that is highly optimized. Code that the average MORT DBA would probably not implement out of the box!

This is a point that's going to go back and forth indefinitely, so I'll simply say that a library will never be able to optimize a query as well as a DBA can, simply because the library or application cannot know which of two tables being joined has 10 rows in it, and which has 10,000,000 rows in it, in order to optimize the query accordingly. Ted doesn't assume that NHibernate doesn't try to tune to the particular database, Ted has just seen said attempts at optimization yield results that micro-optimize and don't yield significant results. Ted is happy to see benchmarks that prove him wrong on this score.

While it was never really discussed Ted’s arguments seemed that they were a little performance related as well. Don’t we all know that performance is the thing you tweak last? And thank god NHibernate is so flexible that you could easily write a sproc to handle a specific operation if you had to.

Well, if you don't think about perf until the very end of the project, you usually find yourself having to either just shrug your shoulders and say, "Well, faster hardware will make it run fast", or backtrack and refactor significant chunks of the application in order to cut out round trips from the system as a whole. I'm not suggesting that you optimize prematurely, just that "right before you ship" is not the mature time to optimize. (Usually I want to start serious perf testing and optimization at the same time that a build gets into QA's hands.)

As for exposing a sproc as a service…. Ludacrious!! The whole point of the service is loose coupling and how can database specific sproc be considered loose coupling. But wait…. Its too much work to build a message object.

Hey, the sproc-as-a-service contention was Rocky's, not mine. Take that argument up with him, not me. But given the ANSI SQL-92 syntax, calling a sproc in a database-neutral way is as simple as "? = { call add_customer(?, ?, ?) }", with the parameters substituted (using either JDBC or ADO.NET APIs) as necessary.

However, it seemed that Ted was arguing that something like UpdateAddress would be fine to implement as an spoc. I don't really see the logic in this as these kind of processes would seem to be better implemented and maintain in a OO language than in a relational language like TSQL.

Frankly, the problem with selectively supporting sprocs in places and not in others is that if clients use T-SQL to talk to parts of the system, and sprocs to talk to others, then you lose the encapsulation benefits of always going through a sproc. (This is true of any encapsulation layer, not just sprocs.) As to certain code being more easily implemented in an OO language, I buy that, and would tentatively suggest that because most RDBMS implementations now support the JVM or CLR internally, this is an area for further research and exploration.

 Congratulations on maintaining your composure in the face of "you're wrong, you're wrong, you're wrong..."

Ted used a fair few cheap debating tricks, which I would have called him up on very quickly...

I'd love to know which tricks those were, so I could use them again.... And you're right, he did a great job maintaining his composure, despite all the baiting I threw at him. I wanted SOOO badly for him to stand up and shout, "Ted, you ignorant slut!", but he just wouldn't rise to the bait. Sigh....

However ... I have to disagree with Ted strongly on one point.

There should *never* be business logic within a stored procedure.

Data logic perhaps (reforming your data, concatenation of data, etc) ... but *never* a business rule (like calculating a sales tax total).

Never is a strong word. Dogma is a dangerous thing, and saying "always" or "never" is a form of dogma. Case in point: If you have a system that needs to be used by both Java and .NET applications, where do you implement your business rules? You could build an XML service in order to implement them in there, or you could build a J2EE-server-hosted interop-technology-accessed component and host them in there, or you could put the rules inside a sproc and implement them in there. Which one has the least complexity and most future-proofed solution? (Another commenter also pointed out that reporting tools will often need to invoke/utilize such logic as part of their reports, which again makes the sproc a useful place in which to put said logic.)

He used a few circular arguments to try to stop you poking holes in his arguments, i.e. he railroaded you by getting you to admit you agreed with him about something that was not what you were actually trying to highlight, and hence closed off the avenue of discussion before you got to highlight your point, I got quite annoyed with him listening to it actually.

Actually, you're not alone: lots of people get annoyed with me. I tried to circle back around to points Ayende wanted to make, but I know that there were other points I wanted to follow up on that I didn't simply for the fact that I didn't want this to go for four more hours. And it could have. Easily.

In this particular debate, much of the arguments were intrinsically circular, because in many cases the discussion rests on value judgements made by the developer or on perceptions held long before the discussion begins. (In other words, whether you agree with me or with Ayende is basically predetermined based on your pre-existing judgment of O/R-M tools and libraries.) I'll also be the first to admit that I wasn't entirely coherent in my arguments, and that this debate could have gone on for four more hours, but as Ayende and I had just done a panel on open-source software for two-and-a-half hours (he sitting on it, me moderating it), I know I was just flat-out exhausted and I had an early-morning flight out of Montreal the next day.

And I am sure at one point he just said something like “you’re wrong, you’re wrong, you’re wrong” i.e. like a politician talking over someone to stop them making a valid point.

Valid point? Then I wouldn't have said "You're wrong". I generally draw a pretty clear distinction between value judgments and stated facts, and I will only tell somebody they're "wrong" when my understanding of the facts are different than what they are presenting. I haven't listened to the recorded show and don't remember what part of the debate being referred to, so I can't clarify the point under question.

"He used a few circular arguments to try to stop you poking holes in his arguments, i.e. he railroaded you by getting you to admit you agreed with him about something that was not what you were actually trying to highlight, and hence closed off the avenue of discussion before you got to highlight your point, I got quite annoyed with him listening to it actually."
Exactly! He also hopped from one argument to the next even though the discussion about the previous argument wasn't finished yet, creating a situation where Oren had to defend, defend, defend and come up with proof why Ted was wrong, which is precisely what you shouldn't do in these debates: If the claimer doesn't have proof, the claimer should shut up :)

Interesting--so now, shoudl I claim that the commerter should shut up, since he claims and offers no proof?

The discussion was also pulled into the area of dogmas rather quickly: stored procedures vs. dyn. sql. Ted made the mistake to use the wrong arguments in favor of procs by using myth after myth and presenting them as evidence while Oren had to defend, defend, defend instead of explaining the real state of affairs in reality. What was also a low thing from Ted was that he took advantage of the fact he's a native English speaker so he could with a bit of more volume overtake any argument easily, he didn't let Oren finish a lot of remarks.

Actually, I'd love to hear what those myths were, since as far as I know, we were discussing the "real state of affairs in reality". If anybody wants to offer up hard evidence as to the "myths" of stored procedures, I'd love to hear or see them. Hard evidence, not value judgments. I think that this whole area is wrapped in value judgments as a general rule, however, and I'll be the first to admit my own value judgments may not be what the listeners or commenters agree with, and that's OK.

What I will NOT stand for, however, is the suggestion that I was trying to take advantage of Oren's linguistic difficulties (of which, I think, he had very few). I may have interrupted Oren, but he interrupted right back in places. As to volume issues, I think this may have had more to do with (what I expect would be) my experience with speaking into a microphone more than anything else. During the panel in Montreal right before this discussion, Oren at one point had to be reminded that if he's going to gesture with a hand, don't use the hand holding the microphone, since it's harder for the mic to work if it's several feet from the mouth.

One thing which struck me was Ted's answer what to change: the table or the code, i.e. what drives what. He couldn't come up with the sole right answer: the abstract entity model is what drives it, as that model defines what a 'customer' is, what relations it has etc. so you can define code or relational model from there, not in a low level table editor or class editor. People who think that writing a class first is different, it's not: the knowledge you use to write the entity class is what's embed and described by an abstract entity model.

There is no "sole right answer"! There never is a "one right answer", to any particular problem. There are solutions to problems that yield particular consequences in particular contexts, and sometimes those consequences are ones you can live with, and sometimes they aren't. Looking for "absolute right answers" is like looking for "absolute truth"--interesting in the abstract, mostly useless in practice.

So i.o.w.: Ted showed he doesn't know much about what a relational model is all about as he kept venting on about tables, procs and other details which are all driven by the abstract entity model which is the foundation of every relational model anyway. (Otherwise how on earth can you decide which fields have to be in table X ? You can't: the reason field A, B and C are in table X is because they're defined as attributes for a given entity X. (P.Chen/Codd entity)

Well, readers/listeners are certainly welcome to take away whatever conclusions they like, but the fact is that I've done the Codd reading (including the 8th Edition of Intro to Database Systems, as well as the various Date essays for the last fifteen years, a la "Date on Databases: 2000 - 2006", from APress) I've studied the predicate calculus and relational algebra, and I'd be happy to have a long drawn-out discussion over Codd's assertions that objects are basically just extensions of the relational model (which I think fails to recognize that an object is instrinsically a combination of state and behavior, given Codd's position on stored procedures in general), for example. Generally speaking, I've found that nobody cares about Codd's assertions or views on things, so I'd welcome another viewpoint on the whole thing.

Overall, it was a discussion which blurred the whole topic, as it was more about what Ted thought about procs and object databases than anything else. I would have respected his opinion if he would have used solid arguments which are founded on knowledge, not myths. I have to give him credit that he didn't use the precompiled myth, allthough he did go for the performance argument: the performance argument is a slipperly slope: because if performance is key, why not put everything in the DB (so also UI) and where to stop to make sacrifices for performance? because that's what putting BL in the DB for performance reasons really is: a sacrifice: you give up programmability and maintainability for performance, but there's no end to that road.

I'm not sure, again, which myths we're referring to here, and obviously I think I do bring solid arguments to the table, but I can't argue against opinion, so that will have to just fly by. Performance arguments are always a slippery slope, but so is elegance and purity. In fact, it's arguable that any dogmatic approach--be it a perf-based one, or otherwise--is a slippery slope to which there is no end.

All in all, I had fun with the debate, my hope would be that Ayende did as well, and if he wants a rematch, I'm happy to take him up on it. Thanks to Richard and Carl for recording it, and thanks to the dozen or so folks in the audience who were willing to sacrifice a late night drinking to sit in the audience and provide a cheering section.

From Bruce Schneier's latest Crypto-Gram:

JavaScript Hijacking

JavaScript hijacking is a new type of eavesdropping attack against Ajax-style Web applications.  I'm pretty sure it's the first type of attack that specifically targets Ajax code.  The attack is possible because Web browsers don't protect JavaScript the same way they protect HTML; if a Web application transfers confidential data using messages written in JavaScript, in some cases the messages can be read by an attacker.

The authors show that many popular Ajax programming frameworks do nothing to prevent JavaScript hijacking.  Some actually *require* a programmer to create a vulnerable server in order to function.

Like so many of these sorts of vulnerabilities, preventing the class of attacks is easy.  In many cases, it requires just a few additional lines of code.  And like so many software security problems, programmers need to understand the security implications of their work so they can mitigate the risks they face.  But my guess is that JavaScript hijacking won't be solved so easily, because programmers don't understand the security implications of their work and won't prevent the attacks.

Paper:
http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf
or http://tinyurl.com/28nzje

Responses to many of the blog comments, by one of the paper's co-authors:
http://www.schneier.com/blog/archives/2007/04/javascript_hija_1.html#c160667
or http://tinyurl.com/yqaoz5

It would be an interesting comparison, to see a rich-client app using "traditional" calls back to a server (via RMI, .NET Remoting, or some kind of messaging system like JMS or MSMQ) weighed against an AJAX app, compared on security holes. My gut instinct tells me that the rich client app would be more secure, but only because using the binary RPC/messaging toolkit obfuscates the wire traffic enough to dissuade the 'casual' attacker, not because it's inherently more secure.

By the way, if you're not receiving Crypto-Gram via email or RSS, you are seriously at risk of writing insecure apps. Think it's all dry and boring security threat alerts? Hardly--check out the "Second Annual Move-Plot Threat Contest". Then tell me whether you think it's funny--or just sad--that there will not only be a real winner to this contest, but that the TSA will, in all likelihood, react the way Bruce predicts, particularly when the major news outlets report the story and it joins the list of fears the public already receives on a daily basis.

More people die every day from automobile accidents than from terrorism. Hell, I'd even bet that on September 11, 2001, more people died from automobile accidents that day than from the Twin Towers attack. (I don't have the statistics to verify that, but I imagine it's fairly easy to find out; right or wrong, kudos to whomever takes the ten or fifteen minutes to research it and send it to me for posting here.)

Ban the automobile! Protect your children from the evil terrorists at Ford, GM, Saturn, Toyota, DaimlerChryseler, and more! Send in the troops to arrest these fiendish perpetrators of unnecessary and senseless deaths to innocent American citizens! (And for God's sake, don't ask how many people die from peanut allergies each year, or we'll lose Skippy and Reese's Peanut Butter Cups too!)

Kathy Sierra, author of the Head-First books and a well-written, well-spoken author around human-computer interface stuff in general, has withdrawn from the blogosphere because of death threats posted to her through the blogosphere. (Be warned, that post has some pretty graphic material in it, definitely not for children.) The result? Kathy has not only decided to stop posting to her blog (for now, hopefully not a permanent state of affairs), but she is in fact in fear for her life:

As I type this, I am supposed to be in San Diego, delivering a workshop at the ETech conference. But I'm not. I'm at home, with the doors locked, terrified.

How incredibly sad for the industry, when one person can effectively douse a bright light like Kathy's. Of course, Kathy has my full support and sympathy--as the author of some outspoken pieces, I've been targeted by some heated voices, but never like anything she's now suffering. I really can't imagine what she's feeling right now, and I really hope I never do.

But the death threats to one side, the anonymous nature of the blogosphere (and the Internet as a whole) is creating a very real danger of shutting down this incredible social environment we call home. Kathy's experience is only the most extreme end of the spectrum; every blogger has seen their share of "virtual hecklers", people whose comments consist of nothing more intellectual than "you're an idiot" or "your mother should be ashamed of having not had an abortion before you were born" (which is an actual comment I received once).

I recognize that when one posts to the blogosphere, one is putting oneself into the public crosshairs, and a certain amount of abuse is to be expected. Hell, sometimes that kind of reaction is what a blogger is gunning for--nothing provokes a good discussion around an idea than an outrageous opinionated statement! I've never questioned the right of people to comment on my blog and call me names (or, at least, what they think is a name--the guy who tries to insult me by calling me "the next Microsoft employee" just really doesn't get it), partly because that's part of the Free Speech idea, and partly because if I can't handle the pressure I shouldn't be running with the big dogs. But folks, let's be honest: if I were to say to you that I get warm fuzzy feelings when somebody posts a personal attack on my character, I'd be lying.

Here's the great admission: It does hurt. Of course it hurts. How could it not?

Nobody likes to be insulted. Nobody likes to have their intelligence called into question. You wouldn't like it if somebody said the same about you, would you?

I'm not suggesting that people who disagree with a blogger's opinions should just roll over and shut up--hardly. You have every right to disagree and offer up your reasons for disagreement. But never lose sight of the fact that behind the blog is a real person, with feelings and a family and the same emotional range as yourself.

Or else we may all find the blogosphere reduced to people screaming shrilly at each other while the smart ones quietly slip away to find a better way to hold their discussions. And that doesn't help anybody.

Think that RedHat is still the open source capital of the Internet, all happy-happy-joy-joy with its supporters and liberal-minded in its goals? Take a look at this and tell me if your mind isn't changed a little:

Enclosed is a copy of the form letter they sent out to many companies that offer Hibernate consulting and training. 

Dear Sir or Madam: 

Red Hat, Inc. has become aware that your company is offering Hibernate training courses. Red Hat does not allow the use of its trademarks without a written agreement. 

Red Hat is the owner of numerous trademarks, including but not limited to, its Hibernate mark, U.S. Federal Registration Number 3135582. RedHat has made extensive use of its Hibernate marks in interstate and international commerce in connection with the advertising, promotion, and sale of its goods and services. Due widespread use, advertising and extensive marketing, the RedHat marks have become famous. 

Red Hat requests that you immediately cease offering Hibernate branded training, as well as any other training that may contain Red Hat marks 

or marks that are confusingly similar. Although you may offer object 

oriented relational database mapping training, you may not use the Hibernate name to promote and advertise your products and services. 

We trust you will understand Red Hat's interest in protecting its valuable intellectual property and ensuring that consumers are not misled as to the source and sponsorship of goods and services sold and/or distributed under the RED HAT marks. We trust this matter can be resolved promptly and amicably and appreciate your attention to this matter. 

We look forward to your reply and request a response no later than {WITHHELD}. 

Sincerely, 

Meredith K. Robertson 

Legal Specialist 

Red Hat, Inc. 

Folks, RedHat has officially moved into the "Big Corporate Entity Seeking Profit At Any Expense" category. So much for the Open-Source-Can-Really-Make-Money-Too-We-Swear poster child, if you ask me...

UPDATE: Apparently, people at eWeek and Yahoo! News posted articles referencing this entry, so let me post some responses to the comments sent in.

First, I don't think this issue is about copyright law whatsoever or IP issues; it's a deeper, more fundamental issue than that. We can certainly argue whether "Hibernate" is a trademarked name or a generic name (such as the discussion over "Kleenex" or the act of copying a paper known as "Xeroxing" it), but that's not the interesting point here either--the point is that RedHat somehow feels that the use of the term "Hibernate" in Bill Dudney's training curriculum is somehow going to imply that Bill has received special blessing from RedHat to do so. Does that mean, then, that I need special blesing from Sun in order to offer "Java" training, or special blessing from Microsoft to offer ".NET" training? If that's the case, then there are a lot of training companies who'd better pull their training courses off the shelf and rethink offering training at all, because there's some serious copyright violations going on out there.

Besides, I thought OSS was a reaction against copyright law.

There's the deeper issue, too, of RedHat's heavy-handedness in this: why is it that companies continually feel that the best way to start these discussions is with cease-and-desist letters? It's pathetic when a corporation like Sun does this (as I went through with my small riff with them over "javageeks.com"), but even more so when an open-source company--who for years has proudly proclaimed their allegiance to "the community" and paraded it around as a compelling reason over commercial "evil corporation" solutions like Solaris or Windows or HP-UX--takes the same path.

I like the OSS stack, and when I write something that's worth putting into play, I will do so. (Arguably, I've already done so--the Java attributes facility I wrote years ago before JSR 175 and JDK 5 shipped was finished by Mark Pollack and used in several OSS projecs, but I call that more Mark's work than my own.) But it's time that we start making the critical realization that an industry cannot rest on the backs of volunteer work. And I, for one, do not want this industry to surrender its commercial aspects; I cannot pay for my house with "community spirit", and frankly, I don't want to give up doing what I love (writing software, and teaching others how to do the same) just because of an idea proposed by a guy who now makes his living from delivering keynotes and ranting about the evils of closed-source. I submit that Stallman would sing a different tune were he in fact still a working programmer with a mortgage and a family to feed.

If RedHat continues with this, they will simply demonstrate that they are, in fact, no better than any of the other "evil corporations", that they are in fact first and foremost concerned with turning a profit. And maybe that's not a bad thing in the long run. I'm certain the employees at RedHat are no more evil than anybody who works at Microsoft or Sun or Oracle. I'm certain RedHat is just as concerned with their image and their standing in the community as those other companies. I'm also certain that, at the end of the day, the people who work at RedHat want to make money doing what they love, just as I and thousands--if not millions--of other programmers do. Why do we think it's wrong for them to do so?

RedHat, you are under no obligation to retract your C-and-D letters. You are perfectly justified in defending your copyright and trademark. But it definitely puts a crimp on the socialistic tendencies that come out of the mouths of the most virulent OSS evangelist for you to do so, and almost puts the whole open-source argument into a strange discussion where now we're just arguing over the quality of the code and the costs... which is maybe where the argument should have been from the beginning, not over "free as in speech" or "free as in beer".

Scott Hanselman (the Zen master himself) posted an interesting piece about coming through the five stages of programming language grief, while wrestling with a .NET project written in Boo (a .NET language based on Python). That Scott should fall prey to the temptation to "doing things in the old way" (meaning he tried to port the project to C# because C# is, of course, the GOPL: God's Original Programming Language) is a touch surprising, because I tend to think more highly of Scott than that, but I have to admit having fallen into the same trap myself, so of course his sins are forgivable.

Amazing, isn't it, how we can forgive or excuse people's actions when we find ourselves doing the same thing?

Anyway, Scott's post highlights the importance of understanding the "Zen" of a particular programming language--its idioms, its approaches, and its strengths/weaknesses/quirks--when you move into it. For most of us, it's always easier to move into new territory with an experienced guide to show you the way. For Java developers, a guide--or, rather, a pair of them--have just made themselves available to you. Stu Halloway and Justin Gehtland (both ex-DevelopMentor instructors and, I'm privileged to say, friends of mine) have published "Rails for Java Programmers", a Java-centric guide to using Rails and Ruby, and a book I highly recommend, on the grounds that it helps "make Rails make sense" for developers used to the traditional Model/View/Controller approach in Java web apps. Weighing in at a pretty reasonable 300+ pages, it's probably one of the most gentle introductions to Rails that I've yet seen, and it's minus all the distractions of Why the Lucky Stiff's intro to Ruby.

Have a look--there's a sample chapter on InfoQ.

(This piece is curr