The Gordian

One Month of Open Source Development in 60 Seconds

2011-12-12T18:01:00.009+01:00

In October Wayne twittered that I'm ruling the Dash statistics for 2011 in terms of number of commits and that I was #4 in 2010. Looking at my usual schedule as a full time committer and lead of the CDO project I'm not too surprised.

Of course I recognize and appreciate that a pretty large team has gathered around the CDO project and is making it increasingly successful. Following our tradition to make even complex systems comprehensible I invite you to follow one month in the open source life of our swarm of little busy bumble bees:

YouTube

Thank you, team, for making CDO!

Thank you, community, for using CDO!

Thank you, gource, for this nice visualization!

CDO 4.0 SR1 and 4.1 M2 are available

2011-09-30T20:26:00.004+02:00

The CDO Model Repository has a new Downloads page that we're quite proud of:

It offers all kinds of nifty features like composite p2 repositories, repository contents pages, automatic release notes and, last but not least, our new help center (available for 4.1 all drops):

The help center contains the full reference documentation and will be augmented with programmer's guide like articles step by step now.

For those who would like to play with CDO to get a first impression how it feels we're now offering example server and client products, ready to be installed on different platforms (see the first screenshot above).

We hope that these new services are convenient for you and we'd appreciate your feedback to make it even better. Happy modeling...

Concurrent Access to Models

2011-07-07T08:27:00.037+02:00

Most people know that EMF models are inherently unsafe to access concurrently from multiple threads. It's immediately obvious when you look at the following code that has been generated with the standard JET templates.

Ed usually argues that it's the application's responsibility to control concurrent access to the model if it knows that multiple threads are involved. The application knows best how to do it efficiently for specific access patterns and ideally how to avoid deadlocks. Note that adding synchronized modifiers everywhere is counter productive. It wouldn't make the model completely thread safe and in addition unordered access would likely end up in deadlocks that are hard or impossible to resolve.

A model is basically nothing more than an object graph and how a particular thread navigates through such an object graph is highly specific to the particular application. As a result the most commonly implemented locking scope is the entire model. Only one thread at a time can access the model, all other threads must block on a single mutex:

The EMF Transaction project supports a protocol for clients to read and write EMF models on multiple threads but it has two major drawbacks:

It is very coarse grained because the locking scope is the entire model.
It is intrusive because each single access to the model must be wrapped.

A one-way road! What if we, instead of letting threads compete for the ability to access the model, hand a separate model copy to each thread. This is neither coarse grained nor intrusive because each thread can access all model elements at all times with normal application code; no wrapper commands are needed.

This approach obviously enables concurrent threads to access the (their) model at any time, but hey, isn't it extremely expensive to instanitate the entire model multiple times? Of course it is! So let's go further down this road and see what can be done to solve the foot print issues.

Let's assume that in the most common scenarios the models can be pretty big but a single transaction, i.e., the number of objects changed between two consecutive commits, is rather small. Then we could refactor our model classes to delegate all model state access to a new kind of entity that can now be shared among the model objects of all open transactions. Let's call these shared entities revisions and their managing container a session.

The model objects are now very cheap in terms of foot print because they only store a pointer to their current revision in addition to some general EMF infra structure such as the list of adapters. The revisions contain all the modeled state plus a version number (which is explained below).

Nice, now the model can be read by multiple threads without main memory being blown up. But with this design the original problem of concurrent write access is not addressed! The modifications that one thread applies to a model object end up in a shared revision, possibly overwriting changes made by other threads.

It's obvious that transaction scoped writes must not alter the shared state. So we refactor our model classes again so that the setters automatically create and link copies of the used shared revisions. Let's call them transactional revisions.

A simple implementation of a commit operation would execute these steps:

The versions of all transactional revisions are checked against the versions of the current shared revisions to detect conflicting commits of other transactions.
Move the transactional revisions into the session.
Notify other transactions so that they can eventually adjust their revision pointers to the new shared revisions. Note that conflict potential in these other transactions can be detected early at this point in time!

That's it! Too simple?

It probably isn't that simple in many ways. But there's already a mature Eclipse technology available that cares for all of the aforementioned aspects and more.

Surprise, surprise, it's the CDO Model Repository, a highly efficient and scalable runtime platform for your models. The following code snippet illustrates how to use CDO to let 100 threads modify the same model:

You may have noticed that in the above example code the commit operation of a background thread can fail because the company object has just been modified by a different thread. With CDO you can easily implement a pessimistic locking strategy by acquiring a single explicit write lock on the company object. Alternatively you can register shipped or custom conflict resolvers with your transactions if you prefer to stay optimistic as long as possible.

Happy multi threading!

Bringing It All Together

2011-06-22T13:25:00.013+02:00

A header that makes sense these days in several regards.

The Annual Release

The committers of dozens of Eclipse projects have worked hard to fix bugs and integrate new features. And today is, once more, the magic day when all this work becomes available to the public in a single combined effort, called Indigo this time.

Traditionally the weeks immediately preceeding the annual release are dedicated to fixing bugs, augmenting the documentation or enhancing the homepage. So much fun!

Release Engineering Tools

It’s my belief that the only project better than a project with a process is a project with a process that is tool supported. This year I’ve taken the chance to invest into the release engineering tools of my project, the CDO Model Repository.

An incremental project builder validates the third version segment of OSGi bundles against a baseline of implementation digests, similar to what PDE’s API Tools achieve for the major and minor version numbers:

A generator for modular help plugins combines the JavaDocs of multiple source plugins and enables cross-references between them:

An automatic promotion service recognizes new builds from the continuous integration, copies them to downloads.eclipse.org, composes them into a number of p2 repositories and generates web pages.

Of course we also deliver a large number of new features with today’s CDO 4.0 release but I plan to write a separate article about those.

Eclipse Demo Camps

Yesterday I’ve been attending the Eclipse demo camp in Braunschweig. Alex has taken a nice photo of my CDO 3D show:

The camp started early, all the presenters managed to keep the schedule and many of us could round up this interesting evening at a local bar, enjoying food and drinks. Next Tuesday I’ll have the pleasure to do the same demo in Hamburg again. I'm going to bridge that time with some decent gardening.

Next Wednesday Martin and I will organize our first demo camp in Berlin. The idea was born at the end of the last EclipseCon in Santa Clara when Mike Milinkovich told me that he’d like to come to Berlin and give an Orion demo. So there we go.

The registrations have already exceeded our minimum expectation of 50 but personally I hope that Berlin and Brandenburg can do better! Please take a minute and invite your friends, colleagues and partners to this event.

The chance to talk to the director of the Eclipse Foundation will not come back any time soon for most of us. The other presenters will contribute to a cool line up, too, of course. I’m looking forward to meeting you next Wednesday evening.

CDO Enters the 3rd Dimension

2011-03-21T09:40:00.000+01:00

Update: The new room is

Ballroom B+C

(not D, as in the printed schedule!)

EclipseCon is near and I'd like to invite you to attend Martin's and my talk CDO 3D on Monday shortly after lunch time.

As you may know or not, CDO is a runtime environment for distributed shared EMF models. Especially for organizations with huge models (e.g. the NASA, banks like the UBS AG, etc.) CDO is indispensible and has become sort of modeling mainstream in the past years.

Although I've always invested a lot into cool animated Powerpoint slides and although CDO comes with really new functionality each year, we've recognized a slight tendency of the conference audience to decide for parallel talks about completely new modeling technology, if they were forced to choose one. This fact (and the guy who shouted "next year we get Pixar Studios" after my last EclipseCon talk) has made me think about new ways of presenting a complex distributed technology. That's why this year's talk is titled "CDO 3D".

We will have no Powerpoint slides anymore but fully focus on real-time demos of a distributed system with a CDO model repository server and two CDO client applications. The client applications have RCP user interfaces, as well as a self-made scripting console that we will use to demo the API usage of CDO and the immediate influence of local CDO calls on the entire system.

In addition we've developed a 3D visualization frontend, that renders the contents and activities in multiple Java virtual machines into a 3D canvas in real-time. We've instrumented these VMs so that the frontend can even visualize the method calls between the Java objects and the network traffic between the VMs. This diagram outlines the basic architecture of our presentation system:

If you're still asking yourself "What the hell is he talking about?" watch this short video:

(click here for watching a larger video)

Of course we'll also talk about some of the cool new features in CDO 4.0 like OCL queries, Blobs and Clobs, cross referencing and referential integrity checks, fail-over cluster and the brand new backend integration with MongoDB. I'm looking forward to see you in Santa Clara!

What exactly is inside that p2 repository?

2010-05-19T19:05:00.006+02:00

Wasn't it nice when we were able to point our web browser to an Eclipse update site and instantly see what's in it? Like with this one.

Has it ever bugged you since that this is not possible anymore with p2 repositories? Like with this one.

I've spent some time (with the help of Dave) to add the generation of a similar HTML outline to the new CDO build system. See our resulting p2 repository:

I'd like to encourage you to provide something similar for your public p2 repository. I just added this Ant markup after the site.p2 generation:

The P2Content.xsl file can be found here. If you apply a nicer HTML rendering than I was able to I'd appreciate some hints or snippets.

Honor, Slides, Webinar, ...

2010-04-06T19:50:00.000+02:00

First I'd like to thank you, the community, for electing me as this year's top committer. This is a tremendous honor for me and a real motivation to keep my effort at the same level as the last six years that I have been working with and for the community. Thank you!

During Jeff Norris' keynote at the EclipseCon it was also nice to see CDO being used for the distributed mission planning and control application of the NASA. In general it was an awesome presentation, almost impossible to top.

Taken from previous year's slides.

My own talk about CDO was not nearly as cool but the room was full and I got some nice compliments. Some asked for the download location of the slides I used. They are available here.

Who is who?

As my slides do not provide much explanation by themselves we will offer an online webinar again. If you're interested, come and learn about the CDO Model Repository and its new 3.0 features on

Thursday April, 29th, 16:00 CET.

The above picture from the Enterprise bridge shows you the moderators of the webinar. Whoever is able to tell who they are can take part in a raffle and win an Eclipse polo shirt (sizes small and medium available)!

CDO goes Offline

2010-03-19T19:30:00.010+01:00

If you followed the catchy title because you were fearing that the CDO Model Repository project could be discontinued, well, then I've chosen the right title. Let me elaborate by starting with a little anecdote:

During a previous conference I talked about how CDO can transparently turn your file based, isolated EMF applications into a distributed cloud of nodes, all collaborating on a central shared model, immediately seeing all the changes that are committed to the repository by other clients.

I was asked what would happen when, due to network failure, a client gets disconnected from the server. Would it be able to continue working in a disconnected mode? At that time I answered that the C in CDO is for Connected (Data Objects) and that we, for this reason, do not offer an offline mode.

Well, while that caused a grin here and there it was kind of polemical and I must say that I've always understood the industrial relevance of being able to work offline. The real reason for not having this mode in CDO has always been the tremendous cost to develop it properly. As an individual full-time committer I just couldn't afford this investment on my own.

But exactly this has changed since and my new main sponsor has given me the opportunity to develop the cool new offline mode for CDO. In fact it is not only a mode, optionally provided on the client side. More exactly it's a new type of a cloned repository. This clone is continously being synchronized with a master repository and can almost be used like a normal repository. Clients are almost not impacted, normally they do not even realize whether the clone is online or offline.

The major challenge wasn't so much the background synchronization of the clone or write-through commits of clients while the clone is online. It turned out that committing to the clone during offline periods and pushing these changes to the master later is even more complex. I'm tempted to slip into the details of the technical solution that I implemented, but the whole purpose of this article is to allure you to my exciting EclipseCon talk:

Scale, Share and Store your Models with CDO

The talk is on Wednesday, starting at 14:30 and I'm going to augment the beginners' overview of the technology with a preview of all the new and the cool stuff that we'll be delivering with the upcoming CDO 3.0 in Helios. And I'm also going to explain why the new offline mode has coincidentally lead to the introduction of branching and merging support in CDO, as well.

I'm looking forward to meet you all (again) in Santa Clara!

Less EMF!

2009-11-02T12:50:00.008+01:00

This year's Eclipse summit was a great success, again. Before I start to chatter about the modeling technologies that I found most interesting, I'd like to point out that there also seems to be some sort of anti modeling coalition. It's clear that the public statement that "Modeling sucks!", without further reasoning, is more likely to create common hilarity than constructive engagement in the challenges and opportunities. A pity that I missed the Foundation 2.0 talk!

I noticed that others took the war against modeling and EMF in particular more seriously. There seems to be a whole industry concerned with devices that shield against EMF and the like. They are sold with the slogan "Less EMF", go figure:

http://www.lessemf.com

Of course these attempts to discredit the value of modeling are doomed to failure, as the overwhelming interest in Eclipse modeling technologies at the past summit demonstrated. The tutorial about Advanced Programming Techniques with EMF and CDO was so overly crowded that the organizers had to take all tables out of the room and make place for almost 100 attendees.

At least the same amount of interested persons stayed in that room to participate in the discussions of the following modeling symposium. All the other talks (24 total) and BOFs about modeling had been extremely well attended, too. Some of them were of particular interest for me and the CDO Model Repository project:

The new EMF Model Query provides an SQL-like query language, cool (Xtext-based?) tooling and an extensible query orchestration and interpretation framework. The SAP team announced that an integration with the CDO server side is very interesting.
Frederic Jouault and Hugo Bruneliere compared Eclipse modeling and Microsoft Oslo technologies and had some ideas how to bridge the two worlds and transform artifacts between both. They mentioned that Oslo misses a model repository.
Cedric Brun demonstrated the Acceleo generator tooling and gave insights to the process of bringing this project into Eclipse.org. The tooling looked so comfortable that I thought I should give generative approaches a new chance in the CDO code itself.
Kenn Hussey and Raphael Faudougave a BOF and a talk on Papyrus, the new integrated modeling environment at Eclipse.org. These ones were really interesting because some large companies announced that they want to participate in a general initiative with the goal of providing a commercial quality modeling tool with various diagramming support, queries, refectorings and a lot more. CDO was seen in the center of this new architecture to provide client-side scalability, model storage and collaboration.
Markus Herrmannsdoerfer gave a talk that I awaited for a long time already. It was about the COPE framework that seems to do a great job to assist with model evolution (they call it adaptation) and the subsequent instance data migration. Very interesting stuff! Many CDO users have asked for more support in this area and it's clear that we need to provide solutions in a world of changing businesses.
Hajo Eichler demonstrated his ideas on executable models. And he did that very well. Last not least because he copied major parts of my own slides. Sure, he asked for my permission, but because he also changed the copyright to his own's Ed announced that we might send the police after him. Two minutes later we could hear their alarms from outside and he got really worried. Poor Hajo!
Goulwen Le Fur gave an introduction to the new Extended Editing Framework project which is about generating "sexy" properties sheets and possibly object data entry forms. I really hope that they add support for reflective models soon, so that we can use this cool technology in our CDO Explorer UI.

Today it's exactly one year ago that I startet blogging and since that time I was allowed to realize how much positive impact a little marketing can have on a technology like CDO. Some of my friends startet a private competition in finding modeling talks at the summit with no mention of CDO. Not an easy task ;-)

I realize that these days more and more modelers are interested in a model repository, either for using it as a runtime platform for their own products or for storing their design time models. I'm glad that we, the CDO team, have forseen this interest and for the future I hope that we can have even more collaboration and consolidation with other efforts in this area:

Please work with us
on adding the cool features to CDO that you need!

EMF Tips #3: Why should I want to generate editors?

2009-09-30T13:54:00.001+02:00

I thought about treating you with more of those beautiful flowers in Ed's garden but there's still material from our trip to Toronto. Thanks to Dave (Dave, the book, not the Google Bear!) and Kevin for organizing cool downtown and clubbing tours. And for demonstrating how dynamic IBM really is. Thanks also to Lynn and Kenn for showing us Ottawa. Damn, from getting almost one finger between Toronto and Ottawa on the map I deduced that it might be an hour's trip. It is not! Canada is sooo big.

So, why should I want to generate editors for my models? Have you ever thought about this? Or are you politely generating these editor plug-ins, just because it's possible? Or fun?

You might remember that I have 28 models in my workspace. Let's, for a moment, assume I generated 28 additional editor plug-ins into my workspace. A lot of code to maintain and we should be absolutely sure that this is (a) necessary and (b) appropriate!

To judge if it's necessary to generate editors on a per-model basis we need to compare the generated code of two such editor plu-ins. Interestingly, it boils down to a single difference in the initializeEditingDomain() method where the ItemProviderAdapterFactory for the model is added to the ComposedAdapterFactory. More interestingly, the editor will continue to function properly even if you remove this model-specific line! The reason is that the ComposedAdapterFactory delegates to a registry of descriptors which are contributed to the extension registry by the edit plug-ins. You see, it's clearly not necessary to have a generated editor per model.

And usually it's also not appropriate to have vast numbers of editors that are all alike. Model editors are a means to implement functionality that is orthogonal to the models. Things like ordering of nodes and properties, changing colors, fonts and so on are achieved by customizing the editor. I really don't want to duplicate all these UI-related, i.e. model-independent, aspects over 28 editors! And don't forget, your model can be used in other generated editors (other than the one that has been generated for this particular model).

All we need is a single generated editor for all our models.

Eventually we'll need additional editors for additional UI-related requirements, but not for additional models. The same arguments are certainly valid for the generated wizards. One difference between the generated editor plug-ins that I did not talk about, yet, is the editor and wizard markup in the plugin.xml. Our reusable editor would at least have to be prepared that it can be associated with different file extensions, depending on the set of deployed model or edit plug-ins.

EMF Tips #2: Tweaking my Genmodel

2009-09-29T09:11:00.001+02:00

The major part of this month I've been on vacation in Toronto and spent a wonderful time with René, Ed and Frank. Ed's garden is as beautiful as one might expect and I was busy collecting evidence of that.

Too busy to keep up with my EMF Tips blog series. In part #1 we discussed ways to easily generate multiple models. Thanks for all the helpful comments.

This part focusses on tayloring and tweaking the outputs of a single generator model. The default Genmodel properties lead to generation of four plug-ins: model, edit, editor and tests.

We will always need the model plug-in itself but often we don't need all of the other three outputs, so how do we exclude particular plug-ins from generation?

The Genmodel has a properties category for each of the output plug-ins: Edit, Editor and Tests. Completely switching off the generation of any of these is as simple as deleting the respective Directory property.

The generator UI will immediately reflect this by disabling the respective Generate menu item. Even the Shift+Alt+G dialog from tip #1 will adjust accordingly.

The next part of this series will focus on the interesting question "Why should I want to generate editors?". For now, you'd know how to avoid it. Stay tuned.

I was just told that there are still three seats available for the Eclipse Modeling Code Camp training that Ed and I will be giving next month (starting October, 12th) in Munich. Don't miss this great opportunity to spend four days with us and become

the world's greatest modeler!

EMF is Awesome!

2009-08-22T08:53:00.004+02:00

This is one of the conclusions in the first part of an article series I wrote for the german Eclipse Magazin. I already blogged about the included example application eDine. Now the article has been promoted to the JAXenter portal, where it can be read by everybody who's able to read German:

Modeling goes Enterprise I

In this article I elaborate on some internal details of EMF regarding scalability (see also my blog How Scalable are my Models?) before I dive into a detailed explanation of the CDO Model Repository.

The second part of this series will show you how to use EMF and CDO to build distributed, scalable and model-based application systems. The comprehensive example that will be included in that article is already available in the Eclipse CVS. I'll leave a note here when the second part is publicly available on JAXenter.

In case there's a translation geek out there, willing to help me translate these articles into English for a broader audience, please drop me a note. A seat in the CDO hall of fame is guaranteed :P

Modeling Stammtisch Details

2009-08-17T16:04:00.006+02:00

Our poll for the upcoming Eclipse Modeling Stammtisch in Berlin was successful enough to arrange for a nice location and time. Jens v. Pilgrim sent me a proposal which I liked, too:

Prater Garten

Kastanienallee 7 – 9
10435 Berlin
(Prenzlauer Berg)

Begin: 18:30
End: Open

For the outside area it's not possible to reserve tables but they promised me that at this early time it'll be next to sure that we don't end up without a table for 25 persons. The rush hour there is only around 20:00.

Thank you, Jens, for the suggestion. We hope to meet you all there in two days...

Eclipse Foundation funds my Project

2009-08-14T08:11:00.007+02:00

Some discussion has been going on about revenue models for open source projects and their committers. Many good ideas, some whining, and also some misconceptions. One of those was brought to my attention several times just recently by users of CDO and by some of my customers. They seem to believe that

The Eclipse Foundation funds my Project

This is simply not true, neither for my projects, CDO and Net4j, nor for any other Eclipse project. The Foundation's revenue, as well as the donations to the Foundation, are spent in a way that more or less suits all projects equally. Staff must be paid, servers operated, marketing be done, and so on.

All projects are responsible for their own funding. In particular the committers are either employees and paid by their employer (who'd better have a good business model for being able to continue to fund open source development) or so called individual committers, in which case they have to look after themselves for their funding or just do the work for their own gratification.

To make a project successful a great deal of marketing has to be done which often incurs additional costs such as conference fees and travel expenses. I tend to think that the community benefits from these marketing efforts in a similar way as from the usage of open source product itself. The more people are using a product the quicker it will mature to something really great. And the needed funding can be distributed among even more shoulders.

I'm clearly an individual committer and I'm usually working full-time on my two Eclipse projects, for more than five years now. This can and will only continue to work if enough users of the project results realize that nothing is really free:

Open source software is free.

Free like in freedom
but not gratis!

I hope this does not sound too much like whining. It's not intended to be like that. In fact I appreciate that more and more companies that reap benefit and revenue from using open source technologies realize the subtle but essential economic mechanisms that guarantee continuation of their business model. I'd like to take this as a chance to thank my own customers: It has always been fun to spend time with you being incredibly creative and productive to our mutual benefit!

EMF Tips #1: How the hell do I generate my 28 models?

2009-08-13T08:31:00.008+02:00

Recently Ed pointed me to a "hidden" feature in EMF which I always thought I was missing. I take this as an opportunity to launch a series of EMF blogs with hints around EMF, starting with:

How the hell do I generate my 28 models?

In CDO and Net4j together we have 28 models, many of them being test or example models. It has always been a hazzle to regenerate them for new versions of EMF having been published. The best approach I was aware of is a manual loop like this:

I always wished there was a view with all genmodels so that I could select multiple genmodels and regenerate them with a single click. I had such a view in GenFw and even an incremental genmodel generator.

I bet you didn't know the default key binding Shift+Alt+G (M2+M3+G)? I didn't! Go figure:

A dialog opens that lists all genmodels in the workspace. The next page lets you select the sub models to be regenerated:

Before you switch to the second page be sure that all the genmodels selectedin page one can be opened with the genmodel editor without errors. Otherwise the wizard could indefinitely block the UI. Apart from this little lesson it works great and will spare me a lot of dumb effort in the future. Kudos to Marcelo for this neat (but somehow hidden) feature!

Eclipse Modeling Stammtisch

2009-08-12T05:16:00.005+02:00

On Wednesday August 19th Ed and Ralph will be in Berlin and we thought it'd be cool to have an Eclipse Modeling Stammtisch together with you. Here's the invitation:

If you are a modeling newbie and don't understand this abstract syntax just drop me a note so that I can come up with an invitation in a general purpose language. Of course I'd use JET for this purpose :P

Don't forget to add yourself to our poll in order to help us finding an appropriate location!

Hoping to see you in a week...

Eclipse Code Camp – Modeling

2009-07-15T10:57:00.001+02:00

You are interested to learn about Eclipse Modeling? You would like to optimize your EMF usage or learn about amazing add-on technologies like CDO or EMF data binding?

Then come to Munich in October and have a thrilling time with Ed and me! We're looking forward to meet you at the

Eclipse Code Camp - Modeling

Meet the Eclipse Directors in Berlin

2009-06-10T16:02:00.004+02:00

I was asked to arrange for a community "Stammtisch" while the Eclipse board of directors is meeting in Berlin next week. It is the first time that the Eclipse board has ever met outside of the USA.

Everybody is invited to join us:

Date: Tuesday, 2009-06-16
Time: 7:00 p.m.
Restaurant: Bavarium
Location: Europa Center, Berlin
Registration: Doodle poll

The Eclipse Foundation will pay for the drinks and the room has capacity for 50 persons. There are no technical sessions planned!

When the Whole is Less than the Sum of its Parts

2009-06-04T09:55:00.012+02:00

I did not know that this scenario is called Reductionism in ancient literature! I only stumbled on it now when I tried to track down why my daily backups started failing recently. Hold your breath:

The other week I installed a new anti virus tool because it better integrates with my software firewall and the rest of that security suite. In fact it found some new potential infections but I did not care too much because detection is heuristics-based. To be safe I kept all those files in the quarantine folder. I even activated the auto-quarantine feature. Anti virus now looked like a good part of my system.

Now my daily backups: For a long time they also were a good part of my system but since last week they did not complete successfully anymore. The same meaningless error message every time. Not cool!

I found out the reason (well, Google helped a lot): The backup by default copies all changed files to a temporary folder. Including my quarantine folder! The new anti virus tool eagerly detects a new infection and moves the file back to the normal qurantine folder, while the backup process is trying to work with it. Bang!

I saw this thing in the computer history museum in Palo Alto ;-)

Amazing how complex and interrelated the problems of modern computer systems can be. My mother used to be kind of a luddite but nowadays she claims to have fun with the computer and the net. I wonder how she would cope with such stuff?

All this reminds me to the recent discussions about technological complexity and simplicity of the real world:

How to explain EMF?

Why is RCP, EMF, p2, databinding... so hard to learn?

If Only it Were That Simple

Target Platform Provisioning

2009-05-29T06:45:00.004+02:00

For CDO and Net4j we used to have a special Ant script that downloads a well-defined set of dependencies and installs them into a target platform that is contained by the metadata section of the wokspace. The same script also cares to setup a well-defined API baseline. While this was handy in the absence of other mechanisms it always suffered from some issues:

Maintenance burden to keep the versions up to date. Since the automated build is designed differently this was redundant and prone of errors.
3rd party bundles were taken from SpringSource which is not a p2 repository. The SpringSource bundles make heavy use of the "uses" manifest header attribute, often resulting in broken configurations.

Some time after reading Chris's blog about the new target platform provisioning I started to play with it and it really was easy. I came up with a simple target definition for CDO:

Initially I started with a "Directory" provisioner for the SpringSource bundles but then I decided to create an own p2 repository at SourceForge.net: Net4j and CDO Plus Updates. This can now be used to provision your IDE as well as parts of the CDO target platform. Pressing "Set as Target Platform" did its job without problems: In the end all bundles compiled without errors.

So, in the future I'd really like to use this great mechanism for provisioning my target platform but unfortunately there's a show stopper: The target definition carries explicit versions for all the configured features and there's currently no way to update them automatically. I'd really wish it was as easy as my IDE updates are nowadays but it turns out that, once the repositories offer newer versions, not only these are not picked up but the target definition editor even refuses to list the old features. I had to start from scratch and this is certainly no better than what we had before.

There's a bugzilla to track the addition of an update button in the target provisioner. I guess that would finally give me what I need to make use of the whole new target platform provisioning. Anyway, this is great stuff and I appreciate very much all the effort that has been spent so far. Thank you guys!

New Project Artwork

2009-04-28T10:37:00.006+02:00

Yesterday I sat down, installed InkScape and worked on the new project logos for CDO and Net4j. Darn it: designing software and designing logos are two different things! Personally I liked this one:

But all my friends complained: "Too childish!!!"
I sat down again and tried something more honest.
Here is the new CDO project logo:

And here is the new Net4j project logo:

Modeling goes Enterprise

2009-04-26T19:26:00.013+02:00

I just finished the second part of my article "Modeling goes Enterprise - About EMF and CDO". It will be published in the Eclipse Magazin next month. Thanks to Sebastian Meyen and Hartmut Schlosser I'm allowed to make the example application, discussed in the article, available in the Eclipse CVS!

The splash picture was taken in my kitchen

The example is a set of applications (IDE, headless, 3x RCP, Servlet) used to support the business of the electronic restaurant "eDine", where they have touch computers at all the tables and at the bar and in the kitchen. Special RCP applications operate on a distributed shared EMF model which is provided by a headless CDO repository server.

Running the Example

1) Install the example

Checkout the "org.gastro.*" plugins via Team Project Set

2) Start the server process

Start the "GastroServer" launch config. It creates a Derby database at "/gastro".
Watch the console output.

3) Populate the repository

Start the "GastroTestClient1" launch config. It opens a runtime IDE with generic CDO support.
Open the "CDO Sessions" view.
Add a new session (green plus button). Enter "tcp://localhost" and "gastro".

Open a new transaction (right-click on the session).
Import the /org.gastro.testclient/inventory.xml resource into "/eDine/inventory".
Commit the transaction (right-click on the transaction or just save the editor).

4) Start the RCP application for table 1 (and optionally for table 2)

Start the "GastroTable1" launch config. It opens an RCP application.
Browse through the menu card and select some offerings here and there.

5) Start the RCP application for the bar

Start the "GastroDepartment1" launch config. It opens an RCP application for the barkeeper.
Watch orders coming in.
Eventually click on order details to mark them SERVED and watch the order disappearing when completed.

6) Start the RCP application for the kitchen

Start the "GastroDepartment2" launch config. It opens an RCP application for the cook.
Eventually click on order details to mark them SERVED and watch the order disappearing when completed.

7) Send an order (if the RCP applications are all started, see steps 4-6)

In the table application open the second shelf pane and send the order.
Watch how the relevant order details "arrive" in the bar and kitchen applications...

8) Browse the menu card via Web

Start a web browser and point it to "http://localhost:9090/gastro"

Enjoy your meal! ;-)

Brandenburger Tor at JAX 2009

2009-04-16T10:05:00.004+02:00

I'm just preparing the slides for my talk at the JAX 2009 conference next week in Mainz, Germany:

Scale, Share and Store your Models with CDO 2.0

Wednesday, Apr. 22th, 2009
08:45 - 09:45

LongTalk[ ] cdo;

2009-03-23T22:21:00.009+01:00

Only by accident I realized that my EclipseCon talk about the CDO Model Repository is allocated in two different rooms at the same time! I'm not yet sure how to manage this new challenge. The conference web schedule lists the CDO talk on Tuesday 11:10 am in room 206 and the printed programme allocates it in room 207. Fortunately both rooms are located side by side...

Those of you who attended my talks previously might notice that I recreated all the slides from scratch. I'm pretty confident that we'll manage to go on an interesting and diverting trip touching all the concepts and features that make CDO a great runtime platform for scalable and distributed models.

With CDO models go enterprise!
You can go there, too...

EMF on Server

2009-03-11T09:28:00.009+01:00

I've been quiet for a while, mostly because of the mega refactoring that CDO is currently undergoing. Did you know that until now a CDO server did not have any dependencies on EMF? The following diagram summarizes what had been the status quo in this context for over two years:

As you can see, all EMF concepts had been converted to CDO concepts directly under the visible surface. It turned out that this approach had several drawbacks:

No generated EOperation logic on the server
No generated EDataType serialization
No EMF tools on the server (Compare, OCL, ...)
Backend integrators can not use EObject
Server extenders can not use EModelElement

So we decided to eliminate these restrictions by applying a two-step refactoring. The first step was to abandon CDOPackage completely and replace it with EPackage everywhere. This included replacements of CDOClass, CDOAttrbute and CDOReference as well. And CDOPackageManager was replaced by a new, very sophisticated version of CDOPackageRegistry. After one month of refactoring and testing the new status quo looks as follows:

In fact this was the biggest and most impacting refactoring since the complete re-write of version 0.7. Here are some numbers:

69378 changed lines of code
1736 changed files
2.8 MB patch file size
13% performance increase

The deployment of the new design will require re-creation of the backends, i.e. export data, re-create database, import data! Most clients will not be affected if they are properly coded against EMF APIs. The HibernateStore will be excluded from the builds for some time and then re-appear as a separate download to compensate p2 issues with missing, non-EPL dependencies.

Kudos go to Simon, who took over when I fell asleep, to Vik, who adjusted the UI and to Martin, who will adjust the HibernateStore. And apologies for the maintenance congestion that was caused by a locked HEAD.

After the merge to HEAD we'll be able to face the second step of the refactoring and make CDO-controlled EObjects available on the server:

This will open the door to some exciting new functionality on the server like:

Commit validation based on OCL
Common query based on OCL
Annotation-driven model mappings
Easier embedding into clients

Don't forget to block an hour for my CDO talk at the EclipseCon!

Can the fish in Ed´s aquarium bark?

2009-01-30T15:33:00.002+01:00

Wow, our Hightech Webinar yesterday was a great success, given these numbers:

Attendance
110 registered – 25th highest out of 48 webinars
95 attended live – 16th highest out of 48 webinars
86.4% of registered attended live – 3rd highest out of 48 webinars

And a lot of fun, too, given these numbers:

Did you find this webinar useful?
91% (39) – Yes
2% (1) – Yes, but it was too technical
7% (3) – Yes, but it was not technical enough
0% (0) – No

I'd like to thank all of you for your interest that you showed by asking lots of questions. In fact so many that I could only answer very few of them during the webinar. For this reason I went through the chat transcript and compiled a reasonable question & answer list. Here we go:

Can the fish in Ed´s aquarium bark?

No, that was Amber.

I played around with EMF binary serialization, it really is compact & fast. So is this just BinaryResourceFactoryImpl then? Is the binary form platform independent?

Yes, BinaryResourceFactoryImpl. It words for Java on any platform.

Can we change the underlying data base to use something like Objectivity instead of relational DB?

Yes, Simon McDuff (CDO team member) is working on exactly that. Basically we are waiting for some IP clearance stuff to make it (the CDO storage adapter) open source. That's the beauty that the persistence vehicle is complete orthogonal. So you can put any type of backend behind it.

How is CDO doing the object-relational mapping? Is there JPA or JDO underneath or homebrewn?

The backend integration is completely decoupled from the repository framework. The default integration is our proprietary DBStore. Together with Martin Taal from the Teneo project we developed a Teneo/Hibernate integration. I heard that Teneo supports JPA, so yes, a CDO repository can work with JPA. For object-oriented backends you need no mapping at all. See the preceding question about Objectivity. And by implementing a handful of interfaces you can plug in your own backend integration.

So the CDO-Teneo integration is not available yet ''off the shelf''?

It is! We are currently working together with a possible new committer to augment the CDO/Teneo/Hibernate integration team and ensure that this component complies to the same high qualitiy standards as the rest of the CDO framework. Currently the CDO HibernateStore is integral part of the CDO SDK but we are considering to factor it out into separate downloads due to legal issues with the Hibernate dependencies.

Any advice for a mature open source ODB?

Due to lack of own experience, no. But we have https://bugs.eclipse.org/252255 to discuss this topic. Please note that we marked it P5 and HELPWANTED to indicate that we will not be able to address these kinds of integrations ourselves. A perfect opportunity to gain committer privileges !

Can I have multiple communication plugins available, i.e. AMQP?

Eike is working to separate out Net4J to better support other communication mechanisms. It would be nice to closely work together with extenders of these new APIs to ensure that they meet concrete expectations. Apart from this effort it should also be possible to integrate new transport technologies via Net4j. Fo this purpose Net4j has a strong separation of the physical transport layer and the application protocl layer (here: CDO protocol).

Is it possible to tunnel through HTTP, so HTTP on port 80 can go through firewalls for communication?

Yes, Net4j comes with an (experimental) HTTP transport layer implementation that supports asynchronous bidirectional communication through http connections.

Am I correct in understanding that a ViewSet is mainly useful when connecting to multiple different repositories?

Yes, we introduced the explicit notion of a CDOViewSet when we supported external references in the framework, i.e. references from one repository to another repository or completely different resource types. Each EMF RescourceSet always has an associated CDOViewSet (when used with CDO) but in the standard case this ViewSet will contain only a single CDO view or transaction.

Does each change increment the version of an object?

No. The version of an object is incremented at the end of a successful commit operation on a the underlying CDOTransaction or CDOXATransaction. In fact the version is part of the primary key of a CDORevision, so a new version is assigned with each new revision of an object.

When does the view acquire the latest version of an object? The first time you access the object, or every time you access the object?

Basically the first time you access an object. Sometimes earlier (configurable pre-fetching) and sometimes later (after remote invalidation).

What happens in case of a conflict (two transactions changing the same object)?

The most important reaction is that the model repository reliantly rejects the second commit attempt. Depending on the local configuration (session.options.setPassiveUpdateEnabled) you might receive early notification about pending commit failure (conflict state of some objects). All this is about detecting conflicts. Quite new is a pluggable mechanism for custom conflict resolvers. As an example we offer a resolver that reduces the conflict granularity down from object to structural features of an object. See transaction.options.addConflictResolver.

Can I access the same repository through different sessions too?

Yes, you can open arbitrary number of sessions to a single repository, even from a single client. But keep in mind that each session maintains a revision cache and should be considered somewhat expensive. Each session can have arbitrary numbers of views / transactions. The objects (empty data wrappers) provided by these views all share the revision instances of the session cache.

Did I understand Eike correctly that changing an object requires a Transaction, which is the only read-write view?

Yes.

Is Audit a ''mode'' of a repository or a view on the repository?

Both. A CDOAudit is a special CDOView on the client side that enables to look at consistent historical states of the whole object graph. As such it is a client side concept. For this to be possible the repository must be configured to support it. As such it is a mode of the repository. Third, the chosen backend (plus integration) must support this repository configuration. As such it is a capability of the storage implementation.

If I disable the audit mode, then no revision data is stored anymore, right?

Yes, if auditing is disabled in the repository, then no historical revisions are stored. Only current revisions. Please note that each storage implementation can have different capabilities with respect to switching auditing on or off. New: the DBStore can switch it off now!

So when audit is disabled in the server configuration and request an audit object, then what do I get? null or a view on the current revision (the only one available)?

If the repository is not configured to support auditing you will get an exception when you try to open an audit view on the client side. So you’ll never be able to hold references to old revisions.

Can I have custom views on the client editor based on different packages (models) I have in the repo? I assume there is a generic editor to handle all the different models I can have in the repo. I need to have different views on the editor based on different models.

Yes and yes. CDO supports multiple packages and multiple resources both in the client and in the repository. You can mix them as you want to. And the generic CDOEditor supports all of this, too.

Do you have references of production apps based on CDO?

Yes, we have. Although I am often surprised to learn that many companies use CDO for a long time before I even get aware of it through some newsgroup questions. I am planning to open a public poll to gather more feedback, stay tuned. We know of many applications in the modeling industry (tooling) as well as in space and aeronautics, automotive, defense, asset management, and so on. If you know of any applications please tell us about!

Why is the server config file not an EMF model?

The main reson is that formerly we had no other EMF requirement on the server side of CDO. This will change in the near future to better support custom EdataTypes and Eoperations in server-side queries. Together with our new Definition Framework (https://bugs.eclipse.org/246623) this will make a perfect fit to configure a CDO server.

Any parallels/differences to MS Oslo Repository (i.e. in philosophy/objectives)?

Ed Merks talked about Oslo in this blog. The idea of CDO is to support any repository, not just one specific one. I think that can make some aspects of Oslo much slicker.

Does the CDO user interface use standard properties viewer? So the Databinding frameworks can sit on top to create custom UIs and Views?

Yes, CDO is pretty much invisible for the rest of the application. Standards should always be usable.

What is the state of CDO Browser project?

We've recently added Common Navigator and Team Provider support. There is also EFS integration on the way (contribution). It is the main focus of the UI sub component to deliver high-quality and re-usable user interface components that make perfect use of the scalable core components of CDO.

In the demo, when you change something in one client, and it appears on the other client, what's the API like for handling that? Do you have to use listeners? Or does it just look like the model was changed by another thread?

Both, you receive EMF Notifications (depending on the local configuration with or without change deltas) and you also can listen to some special events sent by the server. See the FAQ for details.

Wow! Team Provider, cool! It would be kind of natural to have something like the compare view for conflicts. Can team integration be used to handle conflicts?

Team integration is very new and work in progress. But yes, it is our plan to make all the respective CDO core functionality available through the well-known Team support of the Eclipse DIE, including compare and merge. Consider also that while CVS has file level granularity, CDO can handle two clients updating different properties of an individual object. You can't get more fine grained than this...

I saw that a CDOResource can have a „resource path“. Does that mean the "/folder/company" string is processed and treated as an IPath or something anagolous?

A special obejct hierarchy is defined for that, CDOResourceNode (abstract), CDOResourceFolder and CDOResource. They form kind of a virtual file system for resources within a model repository. They can be navigated and queried just like normal objects (in fact they are EObjects). Each such CDOResourceNode has a unique path, but it is always presented as a String. You can convert it easily to an IPath.

Does CDO provide a Validation mechanism?

At the CDO client side you can apply any validation mechanism that you can get to work with regular EMF models. CDO does not offer own solutions in this area. On the server side you can hook your own vetoable ReadHandlers and WriteHandlers with a particular repository. In the future you will also be able to use EMF based technologies like EMF Query, Validation and OCL on the server side, together with your own validators written in Java.

Are there query facilities for querying the models in the repo?

We have a very flexible query framework that can support any type of query language and deliver query results synchronously as well as asynchronously from the server to the client. You can hook either backend-specific or backend-agnostic language handlers into a repository. We would appreciate the contribution of such query handlers. And we are working on the integration of a common query language (OCL).

Any thoughts on data migration? Data migration and data import from/to XMI?

Import and export to any other persistence style that is supported by EMF is also supported by CDO. We have examples for XML/XMI import and export. Automatic data migration, as needed after model evolution, is currently not supported, although we started discussion on this topic in https://bugs.eclipse.org/256856

How about locking, one client can lock the object so that the other clients not allow to change till it's unlocked? Is there any tree-locking facilities in CDO and/or EMF?

Yes and no. We have explicit locking on object level. You can acquire read and qrite locks one one or several objects at once. The contained sub tree of objects is not included! Locks are automatically released when the view/transaction is closed, optionally at commit time. This locking support is part of the CDO core.

Would it be possible to run the CDO server code within an app server - would that make sense at all?

Yes and yes. Each single component of CDO can run in OSGi, standalone or in any imaginable container. Embedding the repository into an JEE server makes particular sense, when the CDO client is a web application in the same container. Then you can use Net4js JVM connector to bypass socket transport. In the near future we will come up with even more direct connection methods (i.e. without Net4j in between).

Though it's called connected data objects, it there some way of using CDO in a kind-of offline mode?

Currently not. When the connection is terminated or breaks down the CDO session is automatically closed, along with all open views and transactions. But due to the tremendous demnad for and usefulness of an offline mode we have made this feature our current top priority. The problem itself is two-fold. Since demand loading will not work when offline we need to checkout partial copies of the central object graph. The ability to cache revisions in the local file system will also provide for even better scalability because will use this ability to page out dirty parts of local transactions. For the switch back to online mode we need a sync/merge mechanism for objects. This has recently been added to support the pluggable conflict resolvers of transactions.

Speaking of transformation, QVT/ATL over EMF/CDO should be possible, right? Would it perform well?

You should be able to use CDO backed models just like any other "normal" EMF model. CDO is effectively transparent so pretty much every normal EMF thing applies. Regarding performance, there is a lot that you can configure in CDO. See this wiki for details.

Which newsgroups to submit thoughts to?

Use the EMF newsgroup and prefix with [CDO]: See this wiki for details.

We need to save locks when user is offline, is that possible?

Currently, when a user is offline, the session is terminated (offline mode for a session is work in progress). Maintaining locks beyond the end of a session is currently not supported by CDO. Locks are automatically released when the view/transaction is closed, optionally at commit time.

Is there dynamic CDO?

Yes. You can register dynamic EPackages with a CDOSession and commit them to the repository. Note, that you can generally only register top-level packages with a CDO session. Nested packages are registered implicitely if they have a namespace URI.

Do I have to regenerate my models?

Currently yes, or you must use a dynamic form of your model. We are working together with EMF Core on a mechanism to support „legacy models“ (i.e. those that are generated, but not for CDO) in CDO. See https://bugs.eclipse.org/247226 for details. Please note that regeneration does not require the Ecore model to be changed! But the regeneration for CDO removes all member fields from the generated classes (reflective delegation) and your hand-written modifications that use these member fields (they should use their accessors!) would not compile anymore.

What about the new EMF index project and server side queries?

EMF Index will work on the EMF side not directly on the servery/repository side. But we are working closely with them to ensure that CDO can nicely fit into an index provider framework.

Are the CDO webinar and the webinar slides available online?

Yes, Lynn will make both available through Eclipse Live. And I’ll check the slides into the CVS and make them available through the CDO wiki.

Is there kind of transaction Rollback mechanism?

CDOTransaction and CDOXATransaction have rollback() methods.We even have save points which you can roll back to. There's a save point snippet in the webinar slides.

If it was just about storing EMF objects in an RDBMS, Teneo would be sufficient I'd think. So I was wondering what other requirements you could have for the whole "bus" thing?

For instance a distributed shared model or the client side scalability for really huge models. CDO provides a clever memory usage with garbage collector support and stuff like partial object loading, partial collection loading. In this sense CDO is like the virtual memory of EMF (Steve suggested: „Demand Paged Virtual Modelling!“).

Hightech Webinar!

2009-01-28T17:48:00.009+01:00

Yeah, it's hightech what we're working on. And it's definitely hightech what we're working with for this purpose:

My new hightech landline headset

During the tests for our CDO Webinar on Thursday with Ed and Lynn it turned out that Skype produces awful feedbacks which requires me to use a landline phone with a headset. Darn, none of my phones has got a socket for a headset! But, as you can see, I'm used to solving problems.

A day later, all of a sudden, my keyboard startet talking to me! Just rubbish, like a baby: rdeeeeeeeeIIIIIIII. And didn't listen to my commands anymore. Gosh, darn it! What a luck that I found an old keyboard that I can use for the Webinar (I put the baby not too far, so that we can try a nicer conversation later). I'll better have some backup mouse devices at hand, too...

Now everything should be prepared and I hope to see many of you tomorrow. You can win a copy of the second edition of the EMF book by attending:

Scale, Share and Store your Models with CDO 2.0

Don't forget to register for the Webinar!

What is a Workspace?

2008-12-14T09:59:00.034+01:00

Stupid question!

It's a space to work in.
Stupid question?

Stupidity, like beauty, is a not context-free

A friend of mine used to complain that we, the guys of the software industry, only have a maximum of four words available to give things a name. That can lead to horrible ambiguities. Acronyms do the rest (see Uncorking CDOs). I agree that meaningful names tend to be longer, which is not always nice, either. Maybe someone can help me to find a shorter name for a strategy class I had to create yesterday:

TakeRemoteChangesThenApplyLocalChangesObjectConflictResolver

Well, workspace, I'm wandering from the subject. Often it seems necessary to look at the roles and responsibilities of a technical concept to guess its exact purpose and derive adequat usage rules. So, to re-word my initial question:

How am I supposed to use Eclipse workspaces?

I fear there is no single truth, given the vast number of responsibilities of a workspace:

Manage my projects, associate them with revision control
Manage my JREs/JDKs to compile my Java projects against
Manage my target platform to compile plug-in projects against
Manage my API baselines for plug-in development
Manage my working and display preferences

And certainly some more. Each of the above responsibilities has its own dependencies and implications. For example the target platform and the API baselines are dependent on the projects that currently exist in my workspace. While there can be multiple baselines defined in the global workspace preferences and assigned to particular projects, the target platform is a global setting for the whole workspace. It can not be defined on a per project base. Since the set of projects I'm actively working on varies over time, this requires frequent change of the target platform definition.

The only constant I'm seeing is the set of my personal usage and display preferences. The way I populate my perspectives, the key bindings I'm used to and all the other things that proofed to be useful for me. Exporting and importing these preferences is also not ideal because it doesn't catch all settings (like stored passwords) and leads to redundancy problems.

My favorite decoration of changes

Now I get the feeling that the implications and inherent lifecycles of these responsibilities do not match particularly good together. In fact I'm living with this feeling from the beginning of my Eclipse experiences. The fact that my usage preferences are kind of a singleton at any point in time I'm somewhat reluctant to the idea of maintaining a bunch of separate workspaces. Or am I missing a trick to operate multiple workspaces on an identical set of IDE preferences?

I know that it's only a default behaviour of Eclipse to create and maintain my projects physically inside of my workspace. With some effort I can link in a set of projects that a physically stored in a folder outside of the workspace. The problem is that each set of open projects in the workspace requires a number of particular baselines defined and a number of partular plugin-ins to be present in the global target platform. Not to speak about the needed JREs and possibly other stuff that is required for the workspace projects.

An additional, but related, problem is that the initial check-outs from a revision control system usually require me to know which of the remote folders correspond to proper Eclipse projects and belong to the overall set of projects required for a larger set of functionality (also often called a project!). I know the concept of Team Project Set files (PSF) but they do not address the issue of required preference settings and their management is somewhat redundant, given that I'm already managing the set of projects directly in the workspace. I regularly forget to add new projects to the PSF files, or remove the deleted ones.

Sometimes the right steps are obvious

What I really would like to see is some convenient and consistent tooling that enables me to swap in and out these sets of related projects, together with all their prerequisites! I don't want to clutter my office with a completely new desk each time someone drops a task for me, buying and arranging new pen and ink each time...

Given that Eclipse is on the market for many years now I find it hard to believe that there is no obvious solution to this all-day problem. Well, maybe it's just that I didn't find it.

Geeks, please tell me about your solutions!

From time to time I had the feeling that Buckminster addresses some or all of these issues. Unfortunately I never managed to realize the exact responsibilities and implications of the concepts that Buckminster offers to materialize workspaces. At least I found it hard to map these concepts to my scenarios. I suspect that each flexible solution in this area can not be darn simple and I promise to put another evaluation on my todo list.

By the way, for my Net4j and CDO open source projects at Eclipse.org I came up with a mainly Ant-based approach to materialize nearly complete workspaces for the different development streams. Basically it's a two-phase process with a bootstrap phase to check out the setup scripts together with the appropriate PSFs. If you're interested, have a look at my description at http://wiki.eclipse.org/CDO_Source_Installation.

CDO workspace bootstrapping

Remoting with IProgressMonitor

2008-12-09T20:39:00.061+01:00

Recently we added optional progress monitoring for remote requests to the Net4j Signalling Platform and I'd like to take this opportunity to explain some of the exciting aspects of Net4j. You can use Net4j to implement synchronous remoting applications as well as asynchronous messaging applications. Depending on the number of Net4j layers you are using you can work buffer-oriented or stream-oriented.

Another multi-purpose technology

The heart of Net4j is a fast and scalable, Java NIO-based buffer switching technology which is completely non-blocking and allows for multiple levels of buffer multiplexing. On top of this buffer-oriented transport layer there is an optional stream-oriented protocol layer which is used to implement application protocols. The framework automatically ensures that multiple such protocols can be multiplexed through a single physical transport connection like a TCP socket and that the transport type can be transparently changed to other mediums like HTTP or JVM.

I think the idea behind Net4j becomes clearer when we look at an example. Let's develop a small protocol to upload files to a remote server with full support of IProgressMonitor over the network. In Net4j this is a single signal (aka communications use-case) of a protocol and we need to provide implementations for both sides of the protocol. We start with the client-side request implementation.

Now the application can create instances of this request and call the send() method on them. The framework in turn calls the requesting() and confirming() methods when the transport layer is able to handle the data. The following example method encapsulates the sending process. Notice how the IProgressMonitor is converted to an OMMonitor.

This simple method can now be used in a workbench action. The transferFile() call is wrapped in a Job to make it run in a background thread and to integrate with the Eclipse Progress view.

The complete source code of this action class is available via CVS. Now we only need a server that is able to receive and handle our request. We start with the server-side request implementation (called an indication).

When the data of an UploadRequest arrives atthe server the Net4j framework creates an instance of our UploadIndication and calls the indicating() and confirming() methods appropriately. Therefor we need to register a signal factory, i.e. a customized protocol. In our case we create the protocol instance on-the-fly inside of the protocol factory.

If the server was expected to run in OSGi/Equinox the only missing thing would be the contribution of this protocol factory to an extension point.

But we want to look at a simple stand-alone version of our upload server.

The complete source code of the server class is available via CVS. To enhance the maintainability of our upload protocol some protocol constants are defined in a common interface. This makes it particularly easier to add new signals.

Now we just need to start the server and watch the console.

And finally we start a runtime Eclipse application with our UploadClientAction deployed. When you click this action a file selection dialog is displayed. The chosen file will be uploaded to the server and stored there in a temp folder. The progress of the upload operation is properly reflected in the Eclipse Progress view and can even be cancelled at any point in time.

This is only one example of the many things you can do with Net4j. Please note that the actual client/server communication in Net4j has some characteristics that differ from other remoting technologies, among them:

There are no discrete marshalling/un-marshalling phases. As the client writes data to a stream this data is internally filled into fixed-size buffers and passed to the transport layer as soon as they are full enough. As a consequence the server already starts reading and processing that data while the client is still busy sending more data.
Multiple virtual channels can be multiplexed through a single physical transport connection. Each such channel can be associated with its own signal protocol and then be used to multiplex arbitrary numbers of signals into both directions.
The client and server roles do only apply while establishing a physical transport connection. Once connected both sides can open virtual channels at arbitrary times and send or receive data, possibly through signals.

A larger example of a Net4j application protocol is the one that connects EMF models with a CDO model repository. It is also an asymmetric protocol and consists of a client-side implementation and a server-side implementation.

I hope some of you found this interesting. Maybe I have some more ideas for articles about Net4j in the future...

Eclipse Demo Camp in Berlin

2008-12-02T11:53:00.016+01:00

Last week I was at the Eclipse Demo Camp in Berlin, my home town in Germany. This was my second demo camp so I was curious how it would compare to the one I visited early this year in Bern, Switzerland.

Berlin photos of my friend Andreas Mösching

It turned out that they were quite similar. A lot of very interesting presentations coupled with a delicious buffet. Another similarity was the presenters' tendency to completely over-estimate their talking time. I remember that my talk at the EclipseCon 2008 also suffered from this a lot. I think I learned from it and I planned to talk only 15 of my 30 minutes and leave the rest for discussion.

The "Deutsche Dom" (main cathedral in Berlin)

My talk about the CDO Model Repository was the first one in a sequence of eight. Fortunately I managed to show my three architecture slides in 10 minutes, followed by a live demo of another 10 minutes. The rest of the time was dedicated to a lot of questions and answers. Very informative for me and the audience. Thank you!

CDO Architecture

After me Tom Ritter from the Fraunhofer Institut described their ModelBus effort. It reminded me slightly to what I saw in TopcaseD framework and indeed Tom talked about a former cooperation. I wonder if somebody would be interested in evaluating ways to integrate CDO with their ModelBus...

ModelBus

Then Volker Wegert from Siemens had a handicap while showing his SAP R/3 Connector for Eclipse RCP Applications: none of the attendees ever faced SAP back-ends. Nevertheless he managed to make it interesting!

SAP R/3 Connector for Eclipse RCP Applications

Very interesting was Jens von Pilgrim's demo of GEF3D. I was amazed to see what they're able to do with 2D user interfaces! With a handful of code changes they turn an ordinary class diagram editor into a multi-layered 3D editor with connections between the layers and so much more. Amazing. And Jens is a collegue of my new CDO committer Stefan Winkler, so I guess I'll hear from him in the future.

Gef3D

Enrico Schnepel explained us how to use GenGMF to ease the development of GMF editors for large metamodels. I also always thought that the GMF's diagram configuration models are so flexible that they fail to easily support the 95 percent cases. Could be worth a look at GenGMF...

GenGMF

One of the talks was not on the agenda so unfortunately I can not remember the name of the student who showed a demo of his distributed shared model editing framework on top of EMF (or GMF?). In his talk he explained that he investigated CDO and found it inappropriate due to the lack of offline support. What a pity that he did not take the time to contact the CDO team. We are currently investigating ways to provide more disconnected modes of model sharing and it would have been so much nicer to co-operate rather than duplicate efforts! I'd appreciate very much his work in the CDO project and he agreed to consider this. Ed, didn't you mention recently how much you enjoy seeing our team grow and prosper? :P

Shared editing in GMF diagrams

Theofanis Vassiliou-Gioles demonstrated their TTworkbench - an extensible Eclipse based test environment - in a very detailed way. I felt like a trainee...

Buffet between the talks

Stephan Herrmann from the TU Berlin gave the last talk: Plugin reuse and adaptation with Object Teams: Don't settle for a compromise! It looked a bit like an alternative approach to AspectJ and his examples were nearly as amazing as the ones at the ESE talk about Equinox Aspects. I must admit that I'm a bit scared about the security implications about such major changes to published and deployed code, un-anticipated by their providers. But it's clear that many things can be achieved with it that were impossible without.

Object Teams

The demo camp started at 6 p.m. and now it was already far past 10. Only two short breaks so most of us looked a bit tired already and I also decided to go home. For future demo camps I would really limit the presentation time to 15 minutes per talk and allow for discussion afterwards. It should be clear that a demo camp is not a training where we should learn the last detail of a tool or technology. It should create interest and the wish to dig deeper back at home.

The Fernsehturm in Berlin

How Scalable are my Models?

2008-11-24T19:43:00.009+01:00

Recently I noticed an increasing hype around the topic scalability of models, paired with comprehensible concerns about the coherence in between. It is clear that, in the context of Eclipse, we are speaking about EMF, the Eclipse Modeling Framework. To answer the headline question we first need to gather a common understanding of what scalability means in this context. We can summarize the things we can do with a model into two categories:

Use the model in main memory
Preserve the model state between sessions

For a model to be scalable it is required that the resource consumption for its usage and preservation is not a function of the model size.

Scalability does not necessarily imply that it is always darned fast to use or preserve a single model object. Rather it guarantees that performance and foot print are the same or at least similar, whether the object is the only one contained in a resource or it is contained in a huge object graph. Usually the resource consumption should be a function of the model change.

Some persistence approaches obviously need to violate this constraint. For example saving model changes to a text file will always write the whole model as opposed to only the changes (respective enhancement requests in the EMF newsgroup showed me that this is not as obvious as I thought before). Even loading a single object usually requires to deserialize a whole resource file.

Other persistence systems like relational databases, object-oriented databases or even proprietary random-access files are likely to provide for more scalable preservation of models. An EMF change recorder could be attached to your resource set and the resulting change description could be somehow transformed into a set of modifications, executed against the back-end in O(n) where n is the size of change.

While each model object is usually an instance of a generated subclass of EObjectImpl there are other ancestors available, too. Understanding the cost of an object can be inevitable when trying to measure and optimize the resource consumption. But even if we know the minimum size of a single object it should be clear that we are unable to achieve real scalability just by reducing the size of our objects. The only way to handle models with arbitrary numbers of contained objects is to selectively load the objects that are currently needed into main memory and make them reclaimable by the Java garbage collector immediately after usage. A system with such characteristics does not focus on the size of single objects anymore. So what is preventing our generated models from being scalable?

The default generation pattern of EMF creates subclasses of EObjectImpl for our model concepts. These generated classes contain member fields to store the values of references. At run-time these references strongly tie together our object graph. In EMF there are two basic types of references, containment references and cross references. Traditionally only cross references can be turned into proxies to be resolvable again later. As of EMF 2.4 containment references can become proxies as well, although this requires a non-default generation pattern and possibly the adoption of the application to create and manage additional resources. It is important to note that turning an object into a proxy only sets its eProxyURI and nothing else. Particularly it does not unset any attributes or references. As a result proxies are always bigger than their unproxied pendants and they still carry their strong references to other objects! Go figure…

Now we could try to manually unset the nasty references that still prevent our objects from being garbage collected. But this can be a tedious and error-prone task. Especially bi-directional cross references can be hard to tackle because of the implicit inverse operations when unsetting one end. While it does not seem completely unfeasible it remains questionable whether the EMF proxy mechanism is appropriate to make our models scale well. To sum up:

Containment relationships between objects in a resource usually prevent from proxying.
Hence only complete resources look like candidates for unloading.
Detection of incoming references is expensive.
Proxying of incoming references does not automatically influence strong reachability.
Manual removal of strong references is at least inconvenient.

It seems as if we are stuck now, but let us step back to look at our model from a distance. In the end, our model is just a directed graph, the nodes are Java objects and the edges are strong Java references. And this last observation seems to be the root cause of our scalability problem! Imagine all these objects had a unique identifying value and all these associations were more like unconstrained foreign keys in a relational database system. We could point to objects without making them strongly reachable. Can we?

Yes, we can! EMF offers a different generation pattern called reflective delegation and a different run-time base class called EStoreEObjectImpl which can be used to implement models that transparently support the needed characteristics. Fasten your seat belt…

Reflective delegation changes the code that is generated for your implementation classes in three ways. Member fields are no longer generated for features. The getters and setters for single-valued features no longer access a member field’s value but rather delegate to the reflective eGet and eSet methods. And the getters for many-valued features return special EList implementations which also delegate to some reflective methods. With this generation pattern we can effectively remove all modeled state from our EObjects, including the unloved strong references. But where does it go instead?

Since we removed the state from our generated classes and the default base class EObjectImpl is not able to store modeled state it is obvious that we need a different base class, which can easily be achieved with the generator property Root Extends Class. While we could write our own implementation of InternalEObject it is usually sufficient to use or subclass EStoreEObjectImpl. Instances of this class delegate all their state access to an EStore which can be provided by the application. We only need to write our own EStore implementation with a dozen or so methods to fulfill the contract and ensure that each EStoreEObjectImpl instance points to an appropriate store instance. I have seen frameworks which maintain a separate store instance for each model object, others let all objects of a resource or a resource set share a single store and others (like CDO, explained later on) are even more complex. I think the right choice depends on how exactly the store is required to handle the object data. Before we dive into CDO’s approach we have to look at a tricky problem that all possible store implementation have to solve.

In addition to the modeled state of an object all stores have to maintain the eContainer and the eContainerFeatureID properties of an EObject. Although it is not immediately obvious the EStore interface only provides methods to get these values but no methods to set them! Since our store needs to provide these values and the framework does not pass them in explicitly we must, if we want or not, derive these values implicitly from the modification method calls (those that can influence the containment) and our knowledge about the model (which are the containment references?). Solving this problem is typically not a one hour task!

Now let us look at how the CDO Model Repository framework faces the problem. Here are some of the requirements for objects in CDO:

Loadable on demand, even across containment relationships
Garbage collectable, if not used anymore
Replaceable by newer versions (passive update) or older versions (temporality)
Easily and efficiently transferable through a network wire

These led to a considerably complex design which I am trying to strip down here a bit:

CDO’s implementation of EObject subclasses EStoreEObjectImpl and shares the same store instance with all objects in the resource set that come from the same repository which, together with the virtual current time is represented by a CDOView. CDO’s implementation of EStore is stateless other than knowing its view. The modeled state of an object is stored in CDORevision instances which represent the immutable states of an object between commit operations. The revisions internally store the CDOIDs of target objects instead of strong references to them. Each object stores a strong reference to the revision that is active at the time configured in the view. A view softly or weakly caches objects keyed by their CDOID. The revisions are cached separately in the CDOSession, by default with a two-level cache (configurable fixed size LRU cache plus memory sensitive cache to take over evicted revisions). Since revisions are immutable they can be shared among different local views.

With this design neither the framework nor the objects and revisions keep strong references to other objects or revisions and the garbage collector is able to do its job as soon as the application releases its strong references. The reflective delegation causes each access to a model property to go through the store, which uses the revision of the object to determine the CDOID of the target object. This id is then used to lookup the target object in the view cache. If the object is missing, either because it was never loaded or it has already been garbage collected, the needed revision is looked up in the session cache. The revision always knows the class of the object so that the view can create a new EObject instance and wire it with the revision. If revisions are missing from the sessions cache they are loaded from the repository server.

I kept quiet about a certain aspect to avoid complicating things at the beginning. Notice that not only the framework but also the application is creating new EObject instances to populate the model. Usually this happens through calls to EFactory methods which are unable to provide the new object with the appropriate EStore pointer. It becomes obvious that CDO objects (like all EStoreEObjectImpls without a singleton EStore) generally operate in one of two basic modes, which we call TRANSIENT and PERSISTENT respectively. In the context of repository transactions and remote invalidation we further refined the hyper state PERSISTENT into the sub states NEW, CLEAN, DIRTY, PROXY and CONFLICT. The transitions are internally managed by a singleton CDOStateMachine:

In the TRANSIENT state, i.e. after the object was created but before it is attached to a view, the object has no CDOID and no revision. The store is by-passed and the values are stored in the eSettings array instead. The attach event of the state machine installs a temporary CDOID and an empty revision which is populated through a call-back to the object. During population the data values are moved from the eSettings array to the revision and at the same time the strong Java references are converted to CDOIDs. Finally the object state is set to NEW. The temporary CDOIDs of NEW objects are replaced after the next commit operation with permanent CDOIDs that the repository guarantees to be unique in its scope and all local references are adjusted accordingly.

Notice that no EObject/CDORevision pair is ever strongly reachable by anything other than the application. And the modeled state of an EObject can be atomically switched to older or newer versions by simply replacing the revision pointer. Since a revision does not store any Java references to other entities it’s easy to transfer its data over the wire. With this design it becomes feasible to traverse models of arbitrary sizes.

CDO provides some additional mechanisms to make such traversals even more enjoyable. The partial collection loading feature, for example, enables to page in configurable element chunks of huge lists and the current EStore implementation is able to record model usage patterns which can be used for pre-fetching of revisions that are likely to be used soon.

If you are interested in learning more about CDO you are welcome in the wiki and the newsgroup. You are also invited to attend my proposed talk at EclipseCon 2009: “Scale, Share and Store your Models with CDO 2.0”

Being at ESE, not in Thailand...

2008-11-22T11:12:00.022+01:00

Usually in late November we are going to different places in wonderful Thailand for vacation but this year the Eclipse Summit Europe was a month later than the all the other years. So I abstained from a big vacation and headed for the Summit in Ludwigsburg. I arrived there on Monday evening but my luggage did not. Never again I’ll ask for priority baggage when checking in with Air Berlin!

Arriving at the airport Bangkok

Fortunately my luggage was delivered to the Nestor hotel before midnight so I could fully concentrate on the fun of the conference. This fun caused an initial hangover on Tueasday, the symposia day. I missed the modeling symposium because I was told that it was already cramped when I arrived. And I did not prepare a position paper with the required minimum of 2 pages. I’d vote for freeing committers and other persons who are known to be involved so deeply from such effort. Later I was even told that the papers had not been checked very strictly. Anyway, I had some really nice talks to different people on Tuesday.

Me and the jungle on Koh Phi Phi

And I was able to attend the BREDEX GUIdancer presentation, given by Alexandra Imrie, who did a really great job. Later I was amazed that she, coming from Liverpool, could speak German without even the slightest accent. They seem to have a nice tool to create , maintain and execute user interface tests and I am happy that they promised to consider providing me with a free license for my CDO Model Repository project. I also met Ibrahim Sallam from Objectivity, Inc. who is currently preparing the offer of free developer licenses for their wonderful and darned fast OO database system (if used in combination with our EMF/CDO stack). We scheduled a more detailed discussion about this effort for Thursday.

More jungle near Chumphon

In the evening we had dinner in a smaller group and this time in a small restaurant with the lovely local food, which I think of is reason enough to have the summit in Schwabenland every year. Here you get the best Rostbraten, Spätzle and Maultaschen ever. Although we had a lot of fun I left early and went to bed to avoid another hangover during my CDO talk next day.

Lovely Thai food

Wednesday started with (a nice breakfast and) six great talks, the most fascinating for me being the Aspect Weaving for OSGi one. Heiko Seeberger and Martin Lippert presented amazing stuff about their Equinox Aspects project. I promised myself to give it a try as soon as possible. Some time after lunch I headed for Cedric Brun’s interesting talk about Team Work with Models : Compare and Merge with EMF Compare. I appreciated that he finished in time because my talk about the most interesting new features for the upcoming version 2.0 of my CDO Model Repository was the next one to follow.

Dragonfly at a pond on Koh Samui

It seemed that I somehow managed to address both, give an initial impression to the newbies and make existing users look forward to the next release. And our next release will really be a major one. Our small team has already implemented 175 bugzillas since Ganymede, many of them being powerful new features. Special thanks belong to Simon McDuff, who spends considerable part of his parental vacation to provide the CDO community with cool features and friendly support!

A really huge guy

To not repeat my former underestimates of talking time I focused on only very few architectural slides and some code snippets to demonstrate some of the most interesting new features:
• External References
• Distributed Transactions
• Structured Resources
• Resource Queries
• Explicit Locking
• Save Points
• Configurable Passive Updates
• Change Subscriptions
• Query Framework

1, 2, 3, search for me!

I squeezed the large audience through my ten slides in only fifteen minutes, which proofed to be a good decision because even the remaining twenty minutes were not enough to anser all of the questions. I was amazed about the great interest in CDO and particularly noticed the increasing concerns about the scalability of models. CDO transparently addresses this sort of issues for example by loading and unloading single instances on demand or by partially loading huge lists of references. It is unbelievable, yet true, that we can easily traverse models of four gigabytes size or more. Depending on the back-end type chosen we can reach load rates of up to thirty thousand objects per second! I believe that such characteristics, together with the well-thought APIs and our prompt support to the community, caused a lot of the hype we are currently experiencing.

Wonderful biota in Thailand

After my talk I enjoyed the presentation of Gilles Iachelini, Marc Hoffmann and Simon Eggler about „Eclipse on Rails: RCP at the Swiss Railway“. It reminded me to an excellent live presentation they gave to me alone on during one of my business trips to Bern, Switzerland. Thank you guys, again! After that I missed the other presentations to have some more discussions on the floors. Dinner, lots of wonderful wine and the chill-out in the Nestor lobby expanded until five in the morning. As a consequence I missed the keynote on Thursday.

What the heck is that?

Ed Merks’ talk about The Unbearable Stupidity of Modeling clearly was one of the highlights of the whole summit! I’m glad that I was able to attend it. Many of the other talks that I marked as interesting in my schedule became victims of some more private discussions. The only exception was Tom Schindl’s presentation about Writing Datacentric applications with RCP+EMF+Databinding. He excited the audience with some really nice design ideas and, last not least, a demonstration of how easy it is to distribute model changes across machine boundaries with CDO. A meeting with some guys from the automotive scene prevented me from having lunch but the results were so promising that I did not care. That’s why I‘m always carrying some chocolate with me. We enjoyed it together.

Ah, a salesgirl and the wind!

As I mentioned earlier I also continued my discussion with Ibrahim about new licensing models for Objectivity’s OO database. They are currently not only exploring ways to provide free developer licenses for API and server runtimes but could also imagine to provide us (the CDO project) with empty skeleton bundles (EPL licensed) to fake p2 at installation time. I’m really looking forward to see our existing integration with Objectivity as a back-end for CDO model repositories being open sourced in the near future. Unfortunately it appeared that the time ran even faster on Thursday and after a last refreshing beer in the lobby, where most of my Eclipse friends met a last time, I headed towards Stuttgart airport to catch my flight home to Berlin. My luggage arrived with me…

Waiting for the flight back home

Thank you all for making ESE one of the nicest events in 2008 and see you at EclipseCon 2009 in Santa Clara!

How safe is a "thread safe" data structure?

2008-11-02T12:22:00.008+01:00

I think it is obvious that no abstract data type can guarantee that any (non trivial) sequence of invocations is atomic (i.e. not interruptible by other threads using the same instance of the ADT) through mechanisms internal to any ADT implementation. Another good example is the common idiom to insert into a map without replacing:

  synchronized (map)
  {
    if (!map.containsKey("key"))
    {
   map.put("key", "value");
    }
  }

As a consequence each public statement about thread-safety of an ADT or one of its implementations is generally only a statement about behaviour of *single invocations* of the public API. But this statement has some value in its own because the client needs to know whether he is expected to protect single invocations as well. Since the JavaDoc of HashMap states that it is not thread-safe clients must protect the following, too, if concurrent access is possible:

  synchronized (map)
  {
    map.put("key", "value");
  }

Otherwise the map could be internally corrupted. Interesting that in the case of the map ADT there is some special API/implementation couple that solves both problems, internal and to some degree external atomicity. A java.util.concurrent.ConcurrentHashMap guarantees atomicity of single invocations with a possibly higher concurrency than external synchronization. And the ConcurrentMap interface offers the putIfAbsent() operation which executes the "not-containsKey-put" sequence atomically (and even much faster because only one hash lookup is needed!). The following is thread-safe without external synchronization:

  String existingValue = map.putIfAbsent("key", "value");
  if (existingValue != null)
  {
    // New value has not been inserted!
  }

Sometimes we have a situation where two data structures together form a unity in the sense that both of them must be modified at a time or none of them to have a consistent state at any time. An example is a bi-directional mapping. While a ConcurrentMap is a good choice for other mutli-threaded scenarios, we usually don't use them for scenrios where multiple data structures are involved because we need external synchronization anyway.
A ConcurrentHashMap allows for higher concurrency than an externally synchronized map but it is more expensive than a completely unsynchronized HashMap. Or in other words, two ConcurrentHashMaps plus external synchronization are much more expensive than two HashMaps with external synchronization.

Apologies for re-iterating stuff that is known to so many already.
It is still Sunday morning...

Alexander and the Gordian Knot

2008-11-02T11:14:00.015+01:00

'... What glory's due to him that could divide
Such ravelled interests; has the knot untied,
And without stroke so smooth a passage made,
Where craft and malice such impeachments laid?'
Edmund Waller ...to the King

Original medallion of Alexander.

Well, when I look outside, this first November Sunday is not so nice. Bugzilla is waiting but it is Sunday! Anyway, I read the newsgroup and found an interesting post about a topic I discussed at different occasions with Ed Merks and other people in the recent past. I looked out of the window and decided to answer. Hold on. I looked again out of the window and said to myself "Is this the moment to start my own blog?". I always thought that I have not much important to tell in the public but then the idea: I solve this problem by declaring "this blog is not intended to tell important things!". Looking at some other blogs this seems to make sense although I know that beauty is not the only thing in the eye of the beholder.

In the end this blog enables me to pull my name in the public mud myself before others do it. For example Ed recently blogged about my cool, EMF based, model repository framework CDO and its relation with the world's financial crisis, as well as some security problems in Microsoft products. On the other hand, given the ten overly productive chinese (is this PC??) locked in Ed's home office, writing all these articles, it is pretty unlikely that I can blame myself for the next disaster much earlier.

Maybe it is best instead to try writing some posts that are semi important at least. I leave that to the eye of the aforementioned beholder, you. Watch out my next article about thread safety...

A super nova knot.

Ahh, apologies that I also leave it to you to find a relation between the gordian knot and modern software development, or not. I need to go, the sun comes out, and it is Sunday...