Re: [mdt-papyrus.dev] Specification of the single file management

[Kenn Hussey <kenn.hussey@xxxxxxxxx>]

Yes, there may indeed be an overhead associated with the use of archives, which is why I suggested an alternative file/folder-based structure...

Cheers,

Kenn

On Mon, Oct 19, 2009 at 12:10 PM, Thomas SZADEL <thomas.szadel@xxxxxxxxxxxxxx> wrote:

Hi Kenn,

In addition to the Thibault's mail, I have a question concerning the 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!

Thanks for your answers ;)

Regards,

Tom

Thibault LANDRE a écrit , le 19/10/2009 17:07:

Kenn,

thanks for your comments.

Kenn Hussey a écrit :

Thibault,

This is a great starting point. A couple of comments/observations:

- 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

You are right. I'll fix it

- I think the requirement to support containment proxies (control/uncontrol actions) necessarily means that more than one physical resource will make up a model

I agree. Each controlled model corresponds to a physical resource.

- 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

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.

- 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

I don't really get this point. Does this mean we should have a (de)serialization mechanism before store our model in repositories ?

- we should also consider "backup" resources, e.g. so that we can support things like autosave

Is the Local History not suited here ?
However we could add a mechanism to perform an autosave that user can configure through preferences.


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 ?

To be clear, we are not "pro single file" or "pro zip". We would like to find the best solution to implement this key functionnality as it will be very difficult to modify our choice in the future.
We have not commited (we could have to) the patch for this reason.

By the way, has anyone tested the patch proposed ?

Regards,

Thibault

Cheers,

Kenn


2009/10/19 Thibault LANDRE <thibault.landre@xxxxxxxxxxxxxx <mailto:thibault.landre@xxxxxxxxxxxxxx>>

    Hi all,

    You will find attached a proposed specification for the management
    of resources in Papyrus.

    Any remarks / comments is welcomed.

    Regards,

    Thibault

    _______________________________________________
    mdt-papyrus.dev mailing list
    mdt-papyrus.dev@xxxxxxxxxxx <mailto:mdt-papyrus.dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

--

	Thomas Szadel Expert Technique - Atos Origin Bureau 1A17
	Les Espaces Saint-Martin 6, impasse Alice Guy BP 43045 31024 Toulouse Cedex 3 Téléphone : +33 (0)5 34 36 34 53 Interne: 36 34 53 Fax : +33 (0)5 34 36 31 00 www.atosorigin.fr

P Avant d'imprimer cet e-mail, pensez à l'environnement. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
P Please consider your environmental responsibility before printing this e-mail. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.