(no subject)

Paolo, Stephen,

Thanks for your replies.  The only disagreement we have so
far would
over the "vs." aspect of my decision.  From my
perspective, it is a big
decision with lots of lost work if I make a bad choice, and
I must
approach it like a business decision (which in fact it is). 
Beyond
that, sure, live and let write software.

A few random thoughts:

Database connectivity: MySQL is the one to do   It would
also be nice
to have ODBC capability.  Drats - make that a must (I have
to talk to
Oracle too).  I am not a big user of RDBs, but they do some
things
_very_ well.  Also, the rest of the world uses them (even
when they are
not a good fit), and the ability to spin off Access
databases as
snapshots has been quite helpful for collaboration.  With
good external
call capabilities, an ODBC layer is just a matter of some
work.

SSL - that's ok, Squeak does not really have them either,
though I
suspect it will via the crypto group.  There is always
stunnel too,
though I prefer to have zero chance of configuration
mistakes leading to
use of clear text communications.  There is always OpenSSL
and FFI.

Seaside?  That means you are doing continuations.

Clearly licensing will require some investigation.  I would
be a fool to
shun VW for runtime fees, only to use something that
(forgive the
alarmism for example's sake) makes everything I write open
to the world.
 That won't be the case, but I do need to ensure that I can:
(1) create
and use software for commercial purposes; (2) be able
sell/license said
software.  I have no problem with giving away improvements
to the system
itself, and would want to do so because it would enhance a
system in
which I would have a considerable investment of time and
money.  Suppose
we want to climb three separate mountains, but need to cross
another
range to get to them; I am suggesting that we collaborate
freely to
cross the first range, and then have the option to sell our
respective
IMAX movies 

I strongly recommend finishing the graphical environment. 
The essential
components for the IDE are the browser, inspector, notifier
(ok so far)
and (ouch!!!) debugger.  The latter is really the star of
the show, and
(forgive me) you do not have a complete Smalltalk system
without it.  As
I said, I am not an XP advocate, but they get several things
right, and
working in the debugger is one of the gems.  A file-out
mechanism should
be easy enough to create.  Harder is to do packaging
(witness the
ongoing struggle in Squeak with dependency).  The Dolphin
approach is to
force the user to define package boundaries; we get by just
fine w/o a
change sorter.

Stephen, re the OS, I do not so much care that it is free as
robust,
well-maintained, easy to use, predictable, and driven by
those
objectives rather than to maximize market churn.  Linux
seems like a
good choice.

Thanks!

Bill



Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwabanest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029



_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Thanks for your replies.  The only disagreement we have
so far would
> over the "vs." aspect of my decision.  From
my perspective, it is a big
> decision with lots of lost work if I make a bad choice,
and I must
> approach it like a business decision (which in fact it
is).  Beyond
> that, sure, live and let write software.

Fair enough.

> Database connectivity: MySQL is the one to do   It would
also be nice
> to have ODBC capability.

Yes, MySQL+ODBC (and possibly Postgres) are enough.

> SSL - that's ok, Squeak does not really have them
either, though I
> suspect it will via the crypto group.  There is always
stunnel too,
> though I prefer to have zero chance of configuration
mistakes leading to
> use of clear text communications.  There is always
OpenSSL and FFI.

Yes, though there are licensing problems and I'd prefer
GNUTLS with FFI. 
    But we got the idea.

> Seaside?  That means you are doing continuations.

Sure I am.

>  That won't be the case, but I do need to ensure that I
can: (1) create
> and use software for commercial purposes; (2) be able
sell/license said
> software.  I have no problem with giving away
improvements to the system
> itself

Fine.  If your software is not itself an improvement to the
system, you 
can license it as you prefer.

> I strongly recommend finishing the graphical
environment.  The essential
> components for the IDE are the browser, inspector,
notifier (ok so far)
> and (ouch!!!) debugger.

As I said, this is a volunteer project.  Current volunteers
are not 
focusing on the GUI, but they do not stop new volunteers to
do so.  So, 
you can recommend finishing the GUI but you have to put your
own energy 
into that. 

That said, it's not a huge task.  A surprisingly big part of
the 
debugger is not necessarily tied to graphical operation. 
There is a 
debugger -- it is slow and has also bitrotted with some
probability, but 
it is there.  And there is a textual MiniDebugger, which
shares some 
code (cut'n'paste) with the real thing.  It would be cool to
refactor 
the common code into a debugging package.

> The latter is really the star of the show, and
> (forgive me) you do not have a complete Smalltalk
system without it.

Agreed.

> The Dolphin approach is to
> force the user to define package boundaries; we get by
just fine w/o a
> change sorter.

We do the same in GNU Smalltalk.  Package boundaries however
are 
implicit in "what the files define".  You would
need a tool to make 
boundaries explicit, i.e. to associate a class with the file
it lives 
in.  What Dolphin does is probably a good model.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk