
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.

3 comments:
Ed, on reflection, I think you're right about the one committer one vote principle. I think the reason that it doesn't make really sense is that it is sort of trying to accomplish two goals at once, and those goals aren't really reconcilable: 1. Assure diversity in organizational representation and 2. Assure that the view of the committer population as a whole is taken into account.
But I'm still concerned with 1, and I'm a little concerned that getting rid of it is creating a gap. There are many committers and contributors that work independently or work for companies that aren't solutions or strategic members. As a thought experiment, imagine that there was an issue where the interests of solutions and strategic members coincided with those of their employees, and that that issue went against the interests of independent committers. Now, imagine that all or most of the committer reps were employees of those strategic/solution members. In this case, the independent committers would have no voice at all. Of course, the solution to this is just to have more committer representatives! Or perhaps we should have slots for individual member committers not from member organizations, but that would be a bit perverse given that the foundation wants to encourage membership. Anyway, I don't really have a good solution in mind here, but I think its a valid concern.
Miles, to address part of the concern, the EMO will limit the number of people from any one organization who can run. I.e., no one organization will be able to run a full slate of representatives and then elect them on mass employing the majority of their numbers. Of course the tyranny of the majority is always a concern. It would be quite easy for a few large strategic developers to elect a slate of candidates from among their ranks. Nevertheless, I'm quite certain that Eclipse's committers are an extremely diverse population, including those working for large strategic members. I feel confident that they will elect people they believe will be fair and will work hard to represent their interests as committers. I'm sure these interests are quite often different from the interests of the organizations for whom they work. Not only that, I'm certain that the board as a whole values the diversity of views that committer representatives bring to the table and would have little to gain from attempts to stack the vote. I suppose you might say I'm quite idealistic...
Dear Ed,
We are very excited to hear your thoughts about our product Sculpture Toolkit.
Sculpture Toolkit is a modeling platform that contains a set of generative components and runtime infrastructures for developing .NET model-based solutions.
Sculpture Toolkit enables you to create your own models 'S-MODEL', textual languages 'S-PAD', graphical designers 'S-DESIGN', and code generators 'S-GENERATE'.
You can watch a quick tour video from our website (http://www.modelingsoft.com/PRODUCTS/SculptureToolkit.aspx).
Thanks for your time,
Best Regards,
--
Ahmed Negm
Chief Technology Officer
www.modelingsoft.com
Post a Comment