Community
Participate
Working Groups
This task is here to discuss about the resource management in Papyrus. It is linked with the specification that can be found on our svn : /doc/DevelopperDocuments/Specifications/Resource_Management.odt
From a message of Kenn : 1 - we should get into the habit of using the term "resource" rather than "file" because, ultimately, it shouldn't matter (to the tool) where/how the content of a model/diagram is stored 2 - I think the requirement to support containment proxies (control/uncontrol actions) necessarily means that more than one physical resource will make up a model 3 - just because compare/merge tooling doesn't support comparison of binary resources out of the box doesn't mean we should exclude it as a native serialization format, at least in my mind 4 - if we want to support arbitrary repositories (e.g. CVS vs. CDO, etc.) transparently, we may need an "internal" storage structure/format that is different from the source/storage format 5 - we should also consider "backup" resources, e.g. so that we can support things like autosave
1 - Fix in the document 2 - Add a comment in the document relative to this 3 - In fact, it is possible to compare zip file. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=273229 I have run a quick test on my environment and it seems to working fine (Text Compare, EMF Compare...). However it is not possible to do any merge. But maybe we shouldn't allow user to merge their models. The *.emf, *.notation, *.di are dependants. I think, merging will lead to more issues than it solves. Advanced users could still unzip/zip their binary resources to merge them. 4 - I don't really get this point. Does this mean we should have a (de)serialization mechanism before store our model in repositories ? 5 - Is the Local History not suited here ? However we could add a mechanism to perform an autosave that user can configure through preferences. 6 - We propose to regroup all the content in a single file (EMF also deals with it really well). We prototyped both solutions, and it ends up that the single file seems to be the best solution. We certainly missed some impacts / functionnalities. Can you give us some arguments why having all the content in a single file is not a good solution ?
From Thomas Szadel : 7 - loading/saving of an archive in EMF. After reading the org.eclipse.emf.common.archive.ArchiveURLConnection class, I'm wondering if, with a huge archive file, the save operation could cost a lot? I'm not really sure, but doesn't EMF update the archive file each time a resource is saved? Because in that case, if I have 3 resources to save, I also have 3 savings (with a temporary file creation)... which can take time!
From Sébastien : 6 - One advantage of zip is its ability to be able to embed other information in any kind of format.
From Kenn : 4 - Sorry for being vague here. What I was trying to say was that, depending on the nature of the repository, there may be a need for an internal (file-based) serialization which is different from the "native" format of the repository. In the case of CDO, for example, we may want/need to use a file-based storage mechanism to work against, for example, in cases where there is no connectivity to the repository. 5 - It would be suitable, although depending on the autosave interval, the user may prefer not to overwrite the original resource (and hence create a "change" in the eyes of the local history) every time the resource is saved. 6 - Having all content in a single file makes it impossible (for example) for more than one diagram, each from a different "model" or "project" to reference a given semantic element. 7 - Yes, there may indeed be an overhead associated with the use of archives, which is why I suggested an alternative file/folder-based structure...
Created attachment 149995 [details] Specification
closed because out of the cope of the Papyrus Bugzilla.
