[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)