(FC-Devel) Repository document

["Arjan J. Molenaar" <A.J.Molenaar@xirion.nl>]

Hi,

I'm having a few comments on the Repository document from Andrey V Khavryutchenko.

After reading it I had the idea that the way of working with it is to distinct from the way Free software works.

Regarding the assumptions:
!) It is assumed that developers are well connected to the storage. My guess is that most developers will connect to the internet every now and then, but the connection is temporaly.

!) Developers are following a modeling process. That will simply not happen... Most of them (us) do not have the time/money to learn a modeling process or are using another process instead (like XP vs. RUP). A modeling process will evolve over time (from chaotic to ...) and someone (like ESR) will write an article about it, but that's it.

From a free software point of view there should be an analogy between code development and modeling:
- Get your own copy
- change the copy
- send diffs to the model maintainer

It is then up to the maintainer to accept/reject the changes.

<brainstorm>
A few constraints can be drawn from the above:
1) A strict component boundry: development should be *very* component driven (like GNOME). It should be easy to find the way from one components model to another (over the internet!).
2) Diffs should be human readable in some way (XML?) This will allow the maintainer to see what has been changed in a glimp.
3) from 1) -> it is not nessesary to have a centralized storage (or the internet should be considered centralized ;-).
4) A layered structure to provide easy understandability (I'm getting way of topic):
,-----------------------.
| 1. GUI/Application    | DIA/Argo/Kuml/...
|-----------------------|
| 2. UML metamodel      | UML metamodel build as versionable ODB objects
|-----------------------|
| 3. Version management | Create a versionable ODB object
|-----------------------|
| 4. Database           | Standard object database (ODMG compliant)
`-----------------------'
(note that the repository takes care of points 2-4)
The UML metamodel is there, so application builders can already make it possible to plug it in as soon as it is ready.

There are thus two points of focus for now:
- UML compliant applications
- Database (which is worked on)

</brainstorm>

Some of the above can be interpreted from the document as well. The document however has many room from speculation. I hope this narrows the view a bit.


Regards,

Arjan