Community
Participate
Working Groups
(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.
Thanks for the insightful input. I'll mark this as a theme to collect further input around the broader topic of improving the data models in the tasks and context frameworks.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn