[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(FC-Devel) Re: Repository Operational Concept Description (Draft)
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
(sorry for that lazyness)
This impacts every software developer using software models in his/her
[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.
Textual: Allow to maintain dependencies
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
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
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
on the definite product - we can start with a "one (model)change at a
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.
add <model> <model-element>
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)
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,