(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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029



_______________________________________________
help-smalltalk mailing list
[hidden email]
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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk