Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Unique Id generation Proposal

Remy, Sven,

It's important to understand why we started putting IDs everywhere.

Obviously, one reason is so that other can contribute model pieces relative to existing well-known elements in the model. For this, you'd like to have "well-known" human-readable IDs, and I think we do allow it. (Tangent: we've talked about using tags of which you can have more than one, instead of IDs, for the underlying matching problem to make things more flexible.)

The second reason is that we have a merge problem, similar to merges in version control systems, or multi-user apps like Wave. Here is why:
1. The application defines in its application.e4xmi file a base model (for example, main menu, perhaps UI elements like views that are always there, etc). This file changes over time as new versions of the application are being developed and released.
2. Other plug-ins add to that model through our model extension point. Plug-ins can be installed and uninstalled. This means that we have a model that results from combining the base model with these contributions. Of course, this means that there is an additional source of change to the model, but it is pretty clear how these contributions get merged into the model.
3. Now it gets interesting: While the application is running, the model objects are being changed. For example, views that were there when the application first started got closed, or menus/toolbars were customized, new views were opened, etc. These changes need to be persisted across sessions, and ideally even across updating plug-ins or the base application.

The hard problem is how you deal with 3. Obviously, if you just persist the resulting model at the end of each session, it will be very difficult to react to changes in 1 and 2. Therefore, our approach (as implemented by Remy) is as follows: On first startup, populate the model as described under 1 and 2. Changes during the session will be recorded as deltas, and we persist these deltas instead of the whole model when we shut down. Then, for subsequent startups, populate the model as described under 1 and 2 and then apply any persisted deltas from 3. If there are deltas that don't make any sense then skip them.

To make this work, you need to be able to relate the deltas to their corresponding objects in the model. Note that they can be relative to *any* model object, not just "well-known" ones. This is where we need the IDs because relative references (especially those using list positions) are too fragile.

Does this make sense?

Boris

Remy Suen wrote on 03/12/2010 07:59:29 AM:
> <sven.efftinge@xxxxxxxxx> wrote:
> > But is it really necessary to allow contributions to every node? Wouldn't it
> > be ok if one could only add
> > children or refer to nodes which have a name/id?
>
> Well, the model is completely "public" unlike how things are in 3.x,
> so even if you don't contribute something through a model snippet,
> you can still programmatically add a random part to some other
> person's stack (for instance).
>
> These changes to the workbench "state" are performed every day by
> Eclipse users when they go 'Window > Customize Perspective...' or
> when they drag one view to another stack or drag one view to the
> "side" to spawn a new stack.
>
> Perhaps I'm misunderstanding something here?


Back to the top