Bug 368203

Description Miles Parker 2012-01-09 18:20:34 EST

(This bug tracks functionality suggested in bug 358554 comment 3. Note that this is being tracked in Context but potentially applies to Tasks and other Mylyn structures as well. For now this is a placeholder for discussion; it is not being contemplated for active development. Contributions and ideas are of course welcome.)

There are many components of Mylyn that work with highly structured data that it would be
nice to be able to access in different ways but with well defined rules to
preserve integrity and so on. Taking a pretty simple example, I looked at
context store. Here it would not be difficult at all to create an EMF model
that could gracefully replace the existing nicely abstracted one. Ideally, the
objects such as IInteractionContext would be modeled objects themselves, but we
could also preserve the existing API. What are the benefits of that? Without
getting into everything that an EMF model provides, I'll randomly throw some
ideas out:

1. Easy distribution and introspection so for example a user could identify all
Interactions of a certain type within a given period and just grab those
elements for a new context.
2. Much more fine-grained ability to slice and dice contexts.
3. Notification, so for example a view could listen for just interactions of a
particular type rather than the current approach of having all bridge
implementations need to manage all interactions that come their way..
4. Edit command support and validation so that consumers can't accidently put
inconsistent information into the context store
5. Transparency of contexts to users so that they could actually see what
they've been doing, analyse it, etc..
6. Transform contexts between workspaces as appropriate.
7. Arbitrary persistence mechanisms, so that contexts could be stored in an XML
file as currently is happening, on an enterprise DB for access from any
workstation, or *in an efficient binary format* so that you don't have to deal
with performance and maintenance overhead of dealing with zip files.
..

And then adding other EMF technologies:

1. CDO: keep distributed enterprise wide contexts updated in real-time across
workspaces.
2. EMF Compare: Users can see the deltas between different contexts to
understand the overlap between various task types, say.
... I'll stop there.

Now imagine the same thing for tasks, activities, etc.. I should be possible to do at least some of this gradually, without disrupting the current API or at least providing a smooth transition path.