Re: (FC-Devel) core design + project steps

[Duane Griffin <duane.griffin@paradigm.co.nz>]

Hi Andrey, all,

Andrey V Khavryutchenko wrote:
> 
> Agreed.  Should repository code be independed from actual repository
> backend such as CVS?  I guess yes..

Yes, I would agree with that.

> If you wish to distribute FreeCASE at Repository Server interface I see no
> problem.  Just implement yet another Secondary Interface Server and voila'
> But distributing repository is difficult and, if we're goind to use CVS as
> the basis, is very difficult.
> 
> My suggestions:
>  - repository is to be located on single node,
>  - network access to be done through Secondary Interface Servers,
>  - if necessary, repository may be replicated as usual CVS repository
>    (that's have separate problems and I don't wish to bang my head against
>     them now)

Yes, I fully agree with that. I suppose what I am saying is that I think that
pretty much everything should be done through the secondary servers, e.g. code
generation, reverse engineering, critics, editors, report generation, etc.

>  DG>  IDE: I am a bit unsure as to what the IDE would be in that
>  DG> diagram. Can Jeff or someone else explain in more detail what that or
>  DG> the command line would consist of?
> 
> Umm... Don't know.  It is disconnected from the rest of diagram.  May be
> Jeff just sketched ICVS<-IDE packages initially and then expanded it into
> the rest of diagram?

Yeah, that sounds right.

> Well, I'm just describing a solution to the problem, not the features we
> have to implement in first cycle :)  I'd better transform this to the
> requirements specification and then, only at use-case level, would
> prioritize them.

That would be great, and a good basis for all of us to use in discussing and
more clearly delineating the scope of the project and it's high level design.

> Uhum...  So actual repository code should be rather independed from the
> metamodel.  Are UML Core Components flexible enough to become the
> interface, which repository code should depend on?  E.g. are they flexible
> enought to represent Concept Graphs?  I think so, but YMMV and I'm
> interested in it :)

Well, firstly I don't have any of the UML docs with me, and I am just going by
none-too-perfect memory :) Having said that, I do believe that the UML
components could be used to represent Concept Graphs (from what I know of
them). As you say, we could then base the repository interface on the UML
metamodel and simply implement Concept Graphs (and other models?) as
specialised UML diagrams using the standard UML facilities for extending the
basic UML models. Could someone with access to the UML specs and a reasonable
understanding of Concept Graphs check on that?

[Snip, argument in favour of UML]

> Thanks for supporting my point.

Anytime, or at least any time I agree with you :)

Cheers,
Duane.

-- 
Duane Griffin
Paradigm Technology Ltd
Phone +64 4 4951000