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

[Andrey V Khavryutchenko <akhavr@compchem.kiev.ua>]

Hi, Danny, all! 

Sorry for being silent, but my commerical project ran off the schedule, and 
you know what does that means...

>>>>> "DW" == Danny Werner writes:


[...]

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

Fixed.

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

Added.

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

Will fix that in next version.

[...]

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

Your suggestion, unfortunately, will lead to problems.  Major modeling
standards have different metamodels and requirement that models could be
retrieved in a standard, different from the original would require model
translation.  And that is *very* complicated task.

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

Yes, you're right.  

Fixed.

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

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

Yes, this was the hidden assumption by me.  Thanks for revealing ;)
I think the best would be to state that every change in the model is
atomic.

Will fix that in next version.

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

Sorry, don't get your idea.  Could you explain?

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

Actually, yes.

[...]

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

I've just picked up the handy CVS term.

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

Ok.  Changed.

-- 
SY, Andrey V Khavryutchenko	http://www.kbi.kiev.ua/~akhavr

Shick's Law:
	There is no problem a good miracle can't solve.