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

Porting for extensibility and maintainability (was Re: larger issue (Re: Linux install misses Tk))



I'd rather take a risk driven approach. Splitting up the camp is one of them,
so let's try and avoid that by not doing anything rash.

1) If at all, a port would have to be at least as functional as the current
version.
2) Anyone who's using pilotmanager now must be able to use the port as well.
3) Dependencies to off-the-shelf components must be less than in the current
product.
4) Performance must be at least comparable.

Anything short of that is not worth doing, in my opinion and may even be
detrimental, because it just adds complexity instead of making pilotmanager
simpler. I think it may be possible to meet those criteria, in which case I
think we have gained extensibility with reusable Java components.

And, no, I wouldn't go top down. The design exists, it's embedded in the
current system, and there are people who understand it. It just needs to be
documented. That can be done and I don't consider this to be a high risk item.
Current risks are:
- a Java implementation may be too slow
- Perl programmers might not feel at home
- current conduits may not be portable


I know it's not popular to talk about risks. It's much more pleasant to talk
about the things we *can* do than about the things we can't. So please add to
this list of risks and then we can prioritize them and address them in order.

Thomas

Ken Rossman - NYC SE wrote:

> > I agree with Ken.
> >
> > We can discuss this thing to death.
> >
> > I'm willing to contribute!
>
> Best thing to do first, probably would be to pick a project manager of
> sorts.  Need to do some top-level designing first (good OO design
> begins with heavy up-front planning).  Get the top-level interfaces all
> worked out, and spec-ed out, and everything else (writing of additional
> conduits and other utility objects (beans?) should fall right out.
>
> (sorry to say, I'm certainly not the guy for that job, though I'd like to
> be able to contribute some small stuff to a project such as this later)
>
> Ken Rossman, NYC SE           212-558-9182  ||  212-558-9329 (FAX)
> Sun Microsystems              Email: Ken.Rossman@xxxxxxxxxxxx
> One New York Plaza, 35th Fl.  SUN Internal: http://noho.East/~rossman
> New York, NY 10004            INTERNET: http://www.columbia.edu/~rossman
>
> P.S. -- I really like the Perl version (and I use it), and I'm not
> interested in shoving it aside in any way, shape, or form.  I just think a
> group Java project like this might be fun to do, even if it is redundant.
> ------------------------------------------------------------------------
> ***********************************************************
> *             This is a public mailing list!              *
> * Please do not publish Sun proprietary information here! *
> *        -  -  -  -  -  -  -  -  -  -  -  -  -  -         *
> *             http://www.moshpit.org/pilotmgr             *
> ***********************************************************


begin:          vcard
fn:             Thomas  Werthmann-Auzinger
n:              Werthmann-Auzinger;Thomas 
org:            Platibus Software Factories, Inc.
adr:            P.O. Box 3719;;;Princeton;NJ;08543-3719;U.S.A.
email;internet: platibus@xxxxxxxxxxxx
title:          President
tel;work:       (609) 716 8486
note;quoted-printable:World Class Solutions With Java For Your Business:=0D=0A=
	http://www.platibus.com ******=0D=0A=
	Iris - a Java Engine for Rational Rose Model Files:=0D=0A=
	http://www.platibus.com/iris
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


SourceForge.net Logo