[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re:
From: |
Paolo Bonzini |
Subject: |
[Help-smalltalk] Re: |
Date: |
Wed, 11 Jul 2007 11:18:38 -0400 |
User-agent: |
Thunderbird 2.0.0.4 (Macintosh/20070604) |
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