[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (FC-Devel) FreeCase (fwd)



Hi again, Andrey, all,

Andrey V Khavryutchenko wrote:
 
[...]
[change-management/repository]
AK> One of the best CM systems, I've
AK> used -- cvs -- goes ok without locking.
 
Is CVS a good starting point for a passive repository too?




[...]
[extensibility, scripting & reporting]

TF = Dr. Thomas Fricke
> TF> 1 Extensibility - good tools must be customizable.

AK> I'd like to restate in the following fasion:
 
AK> 1 Extensibility in the form of documented interfaces, conforming 
AK> predefined standart.

Agreed. Plus an agreed-upon scripting language. I don't care
which one as long as it's Perl. Stop. Forget that. I couldn't
help myself. Let me refrase: I don't care which one as long as
it's an accepted one with lots of code-examples, libraries and
frameworks.

> TF> 1 Reporting. At least +HTML and +rtf.
 
AK> Definitely SGML.  We've to select a DTD and produce user-level
AK> documentation and reports in it.  Good candidates are 
AK> DocBook (large) and TEI Lite (tool support is somewhat
AK> problematic)

Andrey, I don't know DocBook, TEI or TEI Lite. Do you think it's
unwise to start HTML-only? Better: Let's start by using the 
"documented interfaces" you mentioned and some practical extraction
and reporting language ;-) to keep to reporting problems out of the 
FreeCASE core! (To be clear: a good starting set of reporting 
scripts covering most needs _will_  IMHO be in the distrbution).

I'm not impressed by reporting facilities of the commercial
CASE products I've seen. Furthermore: eventually one wants to
present a model/sytem made with the tool in a personal or team
style.

I'ld appreciate your opinion on this.    
 
> >JW> From an implementation perspective, we may be able to pick up
> >JW> some of these features by integrating existing projects.
 
> TF> At first, there should be defined different layers, as 
> TF> the core (where the repository resides) does not need to 
> TF> know the presentation layer, where either the 
> TF> user interface is defined or the printed doc is
> TF> generated.
 
AK> See the _Interface_ requirement.

This looks like we can agree on that. Do we? 





[...]
[distributed nature]
> TF> I could contribute a apache-corba interface module, developed
> TF> for my own studies, which would imply, that some of the
> TF> own studies, which would imply, that some of the 
> TF> presentations could be done in a Java capable WebBrowser 
> TF> (argo running as an applet?). (A reliable ORB is mico,
> TF> with a nearly full standard Corba 2.0 implementation)

By now I think everyone interested in the technicalities of 
distributed computing should have taken a look at

	http://diamant-atm.vsb.cs.uni-frankfurt.de/~mico/ or 
	http://www.icsi.berkeley.edu/~mico/

to assess wether MICO has the ORBs to start with. I feel good about
it, but please anybody who _can_ judge/compare MICO's merits and
do's
and dont's for FreeCASE: Do so and report. If it depends on other
decisions: please state those.

[...]
AK> Good judgment comes from experience, and a lot of that 
AK> comes from bad judgment.

TTYL
				Danny
====
The sooner you make your first 5000 mistakes, the sooner you will be
able to correct them.
                -- Nicolaides (fortune cookie)