Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Specification of the single file management
Title: Raphaël FAUDOU
Hi all,

As more and more remarks are done directly by e-mail on some part or another of the specification, I would like to suggest (recall?) some rules for efficient collaborative work.

1. for important/large/complex features, take time to define a specification document (at least a first draft with a list of UC and requirements). The goal is double:
  • focus on needs and not on solutions (or we will miss the essentials)
  • provide a discussion basis (the document) on which all project members can argue by complementing/refining sentances so that we reach final agreement.
Note 1: We really need a place to put those specification documents. Kenn, what do you suggest? wiki or Svn? (we have the constraint to make it evolve easily and to maintain it).
Note 2: We would like that such a specification document be published concerning the palette.

2. Once a team took some time to elaborate a first specification document, please respect the work and refer to it when reacting. It means:
  • take the time to open this specification document and read it completely
  • complete it if needed by referencing the requirements that you consider as incomplete or add new requirements but ensure that they are consistent with others
  • Provide samples to clarify
3. If the space of solutions must be explored to check faisability, please create a new document or at least a new chapter so that there is no confusion.

Thanks to all
regards
raphaël





TANGUY Yann 176637 a écrit : 
Right.

The model explorer should gives a visibility on models that are stored in a Papyrus project.

These models shoud have several serialization/storage facilities :
- native = di + notation + uml
- archived = zip file
- single file = a single xml file
- multi file = multiple xml file (granularity to be defined... Package ? Namespace ?)

This should be dealt with by an extension point in Papyrus, so that any one may add his own serialization / file management mechanism.

-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de GERARD Sebastien 166342
Envoyé : mardi 20 octobre 2009 11:50
À : thibault.landre@xxxxxxxxxxxxxx
Cc : Papyrus Project list; Kenn Hussey; SZADEL Thomas
Objet : RE: [mdt-papyrus.dev] Specification of the single file management

I think we should have a Papyrus project concept.

-----Message d'origine-----
De : Thibault LANDRE [mailto:thibault.landre@xxxxxxxxxxxxxx] 
Envoyé : mardi 20 octobre 2009 10:44
À : GERARD Sebastien 166342
Cc : Papyrus Project list; Kenn Hussey; SZADEL Thomas
Objet : Re: [mdt-papyrus.dev] Specification of the single file management

The Eclipse project concept doesn't suit your needs ?

GERARD Sebastien 166342 a écrit :
  
One advantage of zip is its ability to be able to embed other information in any kind of format.

-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Thibault LANDRE
Envoyé : lundi 19 octobre 2009 17:07
À : Kenn Hussey
Cc : Papyrus Project list; SZADEL Thomas
Objet : Re: [mdt-papyrus.dev] Specification of the single file management

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


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

--

Image Signature IOC Raphaël FAUDOU
 Responsable cellule Innovation / bureau méthodes
Head of Innovation & Method Definition
Embedded systems & critical systems
Atos Origin

Tel     : +33 (0)5 34 36 32 89
Tel     : +33 (0)6 10 53 50 44
Mail   : raphael.faudou@xxxxxxxxxxxxxx
Atos Origin
6, Impasse Alice Guy
BP 43045
31024 Toulouse Cedex 3, France

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.

Back to the top