2010/8/29 Sudhakar Krishnamachari <[email protected]>

> My two cents long time in my blog on exactly the same subject:
>
> Its great to see a free version of Smalltalk at last measuring up to the
> needs of using it in an business sense and showing it to non-Smalltalker’s
> and the “IT managers” and not put them off. I am sure this is going to make
> it difficult for VA and Cincom to create new small-medium shop sales going
> forward especially with Seaside, Magritte and raft of other frameworks
> actually being born in Squeak. There obviously is the crying need for
>
> High Priority:
> Enusure very high reliability of the base Pharo. No bugs that are not
> fixable by the average developer with a bit of google and sending a few
> emails. If it needs that one expert in one other end.. business continuity
> is hugely impacted
>
> Primary:
> * better-faster VM aka Cog mainstream
> * Highly performant DBMS connectivity natively


Hi and thanks for the notes.
There is NO way to have native Smalltlak driver for propietary databases.
Even if I would love to have the database driver implemented in Smalltalk
rather than calling a C library, this is not possible with propiertary
databases. If you don't have a public protocol or API there is no way to
build the driver. Do you think Oracle or Microsoft would do a Smalltalk
driver? I doubt it.  So....for propietary databases....you have to somehow,
use of the the existing database drivers.

ALL databases have a driver in C, usually called Database Client Library. C
is fast, and we have FFI. That's why SqueakDBX choosed OpenDBX.


> akin to JDBC through to all DBs no DB specific stuff like now, the Squeak
> DBX is not business friendly.
>

Are you talking about SqueakDBX project ?  (http://www.squeakdbx.org/)
If so, I would like you say it is not businness friendly.



> * Comprehensive Web Services + XMLRPC
> * Pharo-Groovy bridge and / or Pharo-Ruby bridge ( or can we make Pharo
> work in tandem with a JVM..!  this will help leverage the tons of frameworks
> in existence even if they are tad slower than native Java)
> * Configuration Management System plugin for SVN
>

There is SqueakSVN project. And I think in SCM they are doing to GIT.


> * Acceleration of easy docs and plugins/ web development related framework
> interfaces from Seaside viz flex/ silverlight: many that are possible as of
> now, but needs a Smalltalk expert to cobble it up
> * Have not really gone deeper with Webclient/ FTPClient/ SMTPClient et als.
> they need to be really simple/ highly reliable/ dumbed down for the average
> coder to pick snippets and make it work
>
> May be lots more.. I can bring in lot more thought this in terms of
> Generic/ Sectoral or Domain/ Type of Apps preferences viz:
> Banking/Insurance/Utilities/Technical/ Web vs GUI etc ...So first we should
> think hard on the segment you want to hit harder..
>
> Secondary:
> * Better tools for GUI Dev and more standard GUI development capabilities
> * Make Pharo easily usable for a team of 100+ developers together in
> one/multiple locations with code synch issues, change / version control ,
> performance ( a host of other stuff included) taken care of.
>

Agree. Torch project seems that could help here. Altoguht Monticello 2 or
similar would be needed.


> * Pluggable to industry standard tools for development: Rational/ Together
> Soft viz for UML creation and conversion to code / reverse engineer code to
> UML
>


Carla worked on UML for this year GSoC project. It would probably be
integrated soon in Pharo.


>
> Follow through with:
> * Pluggable with QTP/ Testing Automation tools.. Actually this is very
> important in the standard large volume development. Makes a huge difference
> for the risk mitigation for the company. really inexpensive , kind of not so
> highly technical staff runs this show in comparison to Unit Tests/ test
> automation through ST code is a more riskier investment and I have not seen
> in JAva/ .Net / or even Smalltalk large legacy projects unit test done and
> maintained well enough
>
>
> -Skrish
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to