Replying to an old mail...
A stable and formal API and persistence format sounds very good.
On the other hand, I agree with whoever mentioned it (Tom I think) that
we are approaching the point where the next change to the save format
concerning the save format of diagrams should be a move to the UML 2.0
Diagram Interchange format.
With risk of restarting the very confusing discussion from last
summer...
If we go for UML 2.0 Diagram Interchange format then it should not be
very far fetched to put the diagram information in MDR and have it
parameterized by a Diagram Interchange meta-model. If that is the case,
two groups of questions arise:
Is GEF ready for this? Can GEF work while having things like list of
figures, color, size, position, and sub-parts accessed from a
repository? Can GEF accept events with changes of things in the
repository? Can GEF work with sizes and positions in floats?
How does this affect the relationship between the involved subsystems in
ArgoUML: Model, Model MDR implementation, Diagrams, and Persistence?
Both these questions are for you, Bob, to answer. A clear "Yes" on the
first group of questions is required, otherwise I'd say, GEF is not
ready for this.
/Linus
> -----Original Message-----
> From: Bob Tarling [mailto:[EMAIL PROTECTED]
> Sent: den 2 september 2006 15:28
> To: [email protected]
> Subject: [argouml-dev] Keeping zargo file compatible with previous
> versions of ArgoUML
>
> There are various reasons why it is not possible to load a zargo file
> from a current release in a previous version of ArgoUML.
>
> I think there are 2 major problems that cause regular change.
>
> 1. Fixing errors in save due to previous ArgoUML bugs
>
> Some of these fixes must not be repeated. By saving a persistance
> version we ensure that a fix is run once and only once when we know
> that it is required.
>
> 2. Use of PGML and reflection to save and load diagrams
>
> The current method of saving diagrams as PGML means every time we
> adjust the composite make up of a Fig then persistence format differs.
>
> The problem comes if we have introduced some new Fig or refactored the
> name or package of an existing Fig. For the current ArgoUML to read
> previous projects we have no problem as the upgrade XSL adjusts the
> project for these changes.
>
> However when a previous version of ArgoUML is used to load such a
> project it will attempt to create each Fig by reflection using the
> class names stored in the PGML. Obviously it won't find these and
> BANG.
>
> In the past this tended to mean some random exception being presented
> to the user, the user creates issues in the database which we have to
> investigate and our reply was always upgrade to latest version.
>
> This is why I introduced the persistence version. A value that
> increments each time such a change has taken place. Instead of an
> exception the user now sees a message asking them to upgrade.
>
> I hadn't previously seen this as a problem because ArgoUML is becoming
> more stable and we want to push users towards that more stable
> release. I've tried to make changes as gradual as possible saving any
> more major changes until after a stable release of ArgoUML.
>
> Changes to the Fig structure are certainly likely. Issue 3238 and
> issue 4426 spring to mind immeditely.
>
> We have problems now though of requirements of
> http://argoeclipse.tigris.org
>
> The argoeclipse project is not planning to keep step with ArgoUML
> releases. They are keeping to their own schedule. This means that the
> latest version of argoeclipse may not be able to read a save file from
> the latest version of ArgoUML.
>
> The only solution I see is to move to a more formal fixed format than
> PGML for which we need to make a reader and writer that will be
> modified for each version. The logical choice with be the OMG diagram
> interchange format but I was hoping not to do such major change for a
> long time.
>
> With all of the above commments I'm not so sure if it's worth spending
> time on issue 4431. This will not solve the requirements of
> argoeclipse as they will have compatability problems anyway.
>
> But it seems we have a catch 22. The requirements is to stabalise the
> persistence format but in order to do that we need to change the
> persistence format.
>
> How do we go about this?
>
> As a slight aside. There has been some talk a couple of months back
> about moving to ArgoUML 1.0.
>
> To my mind the most important thing for that release is not the bug
> count but a stable and formal API and persistence format. I think we
> have some way to go for that. Is that what we should be concentrating
> on now?
>
> Bob.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
