(FC-Devel) Re: Repository Operational Concept Description (Draft)

[Danny Werner <danny@vrijdag.xs4all.nl>]

Hi Andrey, hi all,

Andrey V Khavryutchenko wrote:
 
> Things are moving slowly, but they _are_ moving. 

Thanks to you.
Here some preliminary remarks, I'm still very busy (divorcing,
single parenting, legal stuff) so I don't know wether
I 'll be able to go deeper (I _did_ update some KagiBi pages
to attract the attention to your work, though).

Ok, here goes:
please read this next to Andrey's work 
at http://www.freecase.seul.org/~akhavr/ocd.html
(sorry for that lazyness)

[Current situation]
textual:
This impacts every software developer using software models in his/her
work.

textual:
[Justification for change]
The absence of cheap (preferably free) and easy-to-use software models
repository leads to high costs of usage of software models 
(increased is not appropriate here).

I would like to add: The use of software models 
helps communicating the issues an management of large, complex
systems. The use, communication and maintenance of models, 
however, is nowadays extremely difficult. 

I infer your meaning of the concept of "software model" 
includes "a part of a software model". You might make this explicit.

[change 4]
Textual: Allow to maintain dependencies    

[change 5]
Approach: Don't demand it from the storage, demand that the
models can be _retrieved_ in a form according to those standards.
(In my experience: demanding it from the storage leads to numerous
boring non-discussions)

[change 6]
Same thing: _exchange_ instead of store.
However, if you just mean to say here that the storage format 
must be open source (BTW is KagiBi?), I fully agree.

[Assumptions and constraints]
I agree with - at least - these, but I think there is more.

comment 1. Well, there is a dillemma here: think about concurrent
updates
for a second. If we are going to solve it here (in the repository), 
then we must create a robust OLTP database. OTOH if we are
_not_ going to solve it here, then where? Distributed cooperation
is defenitely a FreeCASE goal. Maybe - though I see you want to put
bounds
on the definite product - we can start with a "one (model)change at a
time" 
repository, just to postpone a lot of technical difficulties until
we solved the more principal questions.

comment 2. Another assumption: Developers work in a constrained, 
strictly defined development/application framework (just to
give an impression: e.g. KDE, or Web-based, or stdin stdout
stderr, language X, etc.)

[Req1-12] call for an interface language, I guess.

create <model>
add <model> <model-element>
checkout <sandbox>
checkin <sandbox>
etc...

I like the term "sandbox" (as opposed to tarball). Your idea?

I don't like req15 as it is.
I'd prefer: "Use XML in the standard model transport."
(and take a database to store them, that's what databases 
are good at)

[Users]
The Repository will not be idiot-proof.
The use of the Repository requires a knowledgable person
(administrator) to periodically check it. 


Hm. Time forces me to stop. Well, I hope this helps.
I also hope there will be more feedback.

Thank you, Andrey :-)

Keep up the good work, have fun,

			Danny