It's been ages since last I blogged. Where does all the time go? EclipseCon came and went in a whirlwind of activity. There wasn't nearly as much modeling content as in previous years and I know more than a few folks were frustrated that I rejected their talks. I didn't bother explaining that this year's selection process reduced me to tears; sometimes it's best to just clam up.
You'll probably be surprised to learn that I actually spent quite a bit of time in my evil secret lair doing cool technical work in recent months. EMF's RESTful persistence framework is heavily focused on stream-based I/O, but sometimes streams are just not what you really need. To enable greater flexibility, we've added two new interfaces to URIConverter: Loadable and Saveable. These make it easy to add a URIHandler that creates facades rather than real streams and via those facades persists a resource's contents in some arbitrary manner, i.e., in a database or some other type of structured repository. If you're interested in details about how to exploit these two new pillars, Byan Hunt blogged about MongoDB integration for EMF not so long ago.
As part of EMF's persistence flexibility enhancements, I vamped up the existing resource implementations as well. Of course they needed to detect the new stream facades in order to delegate appropriately, but more to the point, it's now also possible with a single resource implementation, i.e., XMIResourceImpl, to produce or consume binary using XMLResource.OPTION_BINARY, XML using XMIResource.OPTION_SUPPRESS_XMI, and of course XMI as usual. It's been a well hidden secret up to now, much like the new ODA support Kenn Hussey implemented!
The coolest new feature though is the improved ability to record a set of changes being made to a model and from that efficiently produce a change description that can be sent elsewhere and applied to replicate those changes. It's ironic that a feature so easy to describe is so deceptively difficult to implement. As part of its Change model EMF has long supported a ChangeRecorder that produces a ChangeDescription for this purpose. The problem is that it describes how to go from the current state back to the original state, i.e., it's a reverse delta. It's possible to call applyAndReverse to produce a forward delta, but that modifies the state of the model, i.e. , it's like undo. Of course it's also possible to call applyAndReverse as second time to redo the changes, but clearly that's not very efficient nor desirable when there's a user interface updating in response to all the changes. To address that problem, we've implemented copyAndReverse so that we can produce a serializeable forward delta without changing the state of the model itself. You might want to try it out and help stamp out any remaining bugs.
At the beginning of May I traveled to Germany for JAX and met up with a bunch of my friends for an Eclipse modeling day. The presentations and discussions were in German, so that was very tiring! Can you name all the Eclipse committers in this picture?
As part of the JAX trip to Europe, I spent some time in the Netherlands; I was born in Rijswijk and I took my mother long to visit with her family there while Frank and I stayed in Den Haag and then Amsterdam. I've never been to Amsterdam before and we happened to be there for Koninginnedag. That was quite amazing. No one can pack more boats on a small canal than the Dutch! The fact that their raft was being pushed under by the crowding boats didn't bother these guys one bit.
Not long after getting back from that, it was time for CodeGen 2011 in Cambridge where I did a keynote on the last day. That was a very interesting conference. I met lots of new people. I hope I'll be able to attend again next year. Mark Dalgarno, the conference organizer, did a great job. He even included a very memorably outing to experience punting on the Cambridge waterways.
Since then, like so many of you, I've been caught up in the final frenzied daze of Indigo. With that almost behind me, I am looking forward to a trip to Raleigh, North Carolina Monday for the Eclipse Board meeting. Speaking of which, the foundation is proposing some updates to the Eclipse Bylaws, so the committer representatives took the opportunity to propose a change to how we are elected. In particular, we looking to deliver on the one committer one vote principle. We're quite pleased about that and hope you are too.
Use and Misuse of Statistics
4 weeks ago