Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-papyrus.dev] Wiki page : Specification 
Hi all,

I have created a page on the wiki to summarize all the specifications :
http://wiki.eclipse.org/Papyrus_Developer_Guide/Specifications
Like this, everyone can have quickly access to the on going discussion / specification. 

It is a wiki, so feel free to update it as you want.



- For the moment, I haven't migrate the discussion we had on a wiki page.
We forgot Bugzilla on the possible solution which I think is a better candidate than a document or a wiki to discuss.
So I created a task (with the keyword [Specification] and ) to regroup all our discussions. I identified each part of a discussion with a number. Doing this task, I though it is surely more interesting to create a subtask for each specific discussion (for exemple the "internal storage") which will be closed when we reached a commom solution. 

If you think it is not a good solution, we can migrate to wiki.
- I think it is important to have a specification (without solutions), to regroup requirements we would like to reach, store as a file format (odt) in our repository. I add a folder "Specification" in "/doc/DevelopperDocuments/". 


Here is the proposed process :
- Create a specification with a set of requirement
- Create a global task on our bugzilla to refers to this specification
- Store this specification under the Papyrus repository
- Update the wiki on specification
- Discuss about the requirement / solution
- Update the specification accordingly
- Create development tasks that refers to this specification


Any idea / comment / remark is welcomed.
The idea is to find a better way to share our ideas / needs.

Regards,

Thibault



Kenn Hussey a écrit :

Thibault,
As Raphael has suggested, we should probably move this discussion to the wiki. In the meantime, here are my answers to your questions: 

    - 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 ?
KH > 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. 

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

Is the Local History not suited here ?
KH > 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.
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 ?
KH > 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. 

Cheers,

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

    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>
        <mailto: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>
        <mailto:mdt-papyrus.dev@xxxxxxxxxxx
        <mailto:mdt-papyrus.dev@xxxxxxxxxxx>>

           https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev




begin:vcard
fn;quoted-printable:Thibault Landr=C3=A9
n;quoted-printable:Landr=C3=A9;Thibault
org:Atos Origin - Agence Sud-Ouest ;Systems Integration
adr;quoted-printable;quoted-printable:5, avenue Albert Durand ;;Batiment A=C3=A9ropole ;Blagnac;Midi-Pyr=C3=A9n=C3=A9es;31701;France
email;internet:thibault.landre@xxxxxxxxxxxxxx
tel;work:+33 (0)5.34.36.34.49
note;quoted-printable:D=C3=A9veloppement durable, anticipons pour notre avenir / Sustainibility=
	, advance our future=0D=0A=
	P N'imprimez ce mail que si n=C3=A9cessaire / please consider your enviro=
	nmental responsibility before printing this e-mail.=0D=0A=
	Ce message et les pi=C3=A8ces jointes sont confidentiels et r=C3=A9serv=C3=
	=A9s =C3=A0 l'usage exclusif de ses destinataires. Il peut =C3=A9galement=
	=C3=AAtre prot=C3=A9g=C3=A9 par le secret professionnel. Si vous recevezc=
	e message par erreur, merci d'en avertir imm=C3=A9diatement l'exp=C3=A9di=
	teur et de le d=C3=A9truire. L'int=C3=A9grit=C3=A9 du message ne pouvant=C3=
	=AAtre assur=C3=A9e sur Internet, la responsabilit=C3=A9 du groupeAtosOri=
	gin ne pourra =C3=AAtre recherch=C3=A9e quant au contenu de cemessage.Bie=
	n que les meilleurs efforts soient faits pour maintenir cette transmissio=
	n exempte de tout virus, l'exp=C3=A9diteur ne donne aucunegarantie=C3=A0=
	 cet =C3=A9gard et sa responsabilit=C3=A9 ne saurait =C3=AAtre recherch=C3=
	=A9e pour tout dommage r=C3=A9sultant d'un virus transmis.=0D=0A=
	=0D=0A=
	This e-mail and the documents attached are confidential and intended sole=
	ly for the addressee, it may also be privileged. If you receive this e-ma=
	il in error, please notify the sender immediately and destroy it. As itsi=
	ntegrity cannot be secured on the Internet, the Atos Origin group liabili=
	ty cannot be triggered for the message content. Although the sender endea=
	vours to maintain a computer virus-free network, the sender does notwarra=
	nt that this transmission is virus-free and will not be liable forany dam=
	ages resulting from any virus transmitted.
url:http://www.atosorigin.com/
version:2.1
end:vcard

Back to the top