Re: (FC-Devel) Update

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

Hi, Jeff! 

Sorry for such long pause.

>>>>> "JW" == Jeff Wolfe writes:

JW> I added a link to this site from the freecase details page.  If you
JW> could add a link back to the project, I think it would be helpful.
JW> With a persistent link, maybe more people will see them and comment.

Ok.

>> >From the architectual viewpoint, the repository breaks nicely in tree
>> packages:
>> a. the UML package, that provides the client functionality b. the
>> persistence package, that stores the UML data in a storage c. the CM
>> package, that deals with checkouts, updates, commits, etc.

JW> I just want to clarify my understanding.  For (a), are you referring to
JW> the interface provided to the client to access the information?

Yes.

JW> Several people have suggested that we use an architecture that will
JW> support other modeling languages in the future.  Would it be better to
JW> provide a more general meta-model interface, and force the client
JW> software to turn this into UML?  

Won't this take too much responsibility to the client?

JW> Perhaps we could have a meta-model interface and then allow server-side
JW> plug ins for UML and future models.  These plug ins could act mostly
JW> like a translator.  

Yes, that looks better.  So (a) should be just one of possible plugins.

JW> As in all client server systems, we need to strike the proper balance
JW> between work done by the client and work done by the server.

JW> Then, (b) could focus strictly on storing the meta-model and would be
JW> isolated from all other details.  Now for another question, if the
JW> repository stores model information, where and how do we store document
JW> info?  I'm talking about things like page layout, how to display class
JW> detail (folded, unfolded), etc.  It is my opinion that the model should
JW> be separated from the presentation documents, but also that the model
JW> should reflect the current contents of the documents.  Does this make
JW> sense?

Yes.  UML metamodel doesn't specify the visual modeling part, so we've
figure it ourselves.

JW> Finally, for (c), we have discussed using cvs.  This is certainly a
JW> good move.  Why should we also try to create a revisioning tool?

We shouldn't.  The (c) should be the interface to the cvs.

JW> However, we need to make sure that we don't create a document format
JW> that gets corrupted easily.  Interesting things can happen when dealing
JW> with versioning.  Can someone shed some light on whether or not this is
JW> likely to be a problem?

I'm using cvs for year and never ever got a corrupted file.  All merge
tasks are easily solved by emacs's ediff and emerge.

[cdif]

JW> The only major problem I see is that the actual specifications are not
JW> free.  Is this really a problem?  I don't think so.  There is a lot of
JW> free information on their site.

Glancing though cdif documents makes me think it's quite easy to implement
UML metamodel storage on top of cdif format.

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

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