Certainly all the Smalltalk community should thank ESUG by the
continous support to lot of initiatives.

Thanks ESUG.


2011/3/4 Mariano Martinez Peck <marianopeck at gmail.com>:
> We are really happy to announce that ESUG will sponsor us once again through
> the ESUG Summer Talk project. This means that we have reached the ESUG
> expectations and that they still think that relational database access is an
> important matter in Smalltalk.
>
> One important thing is that we are going to rename the project (we are still
> working on it) since SqueakDBX runs not only in Squeak but also in Pharo,
> and there have been even ports to Dolphin. What's the reason for this
> decision? Because we do not want to couple ourselves to a smalltalk dialect
> nor to OpenDBX, because our project is much more than that (later I will
> tell you about our plans). So, these are some of the possible names:
> ObjectPark, SmallParking, Parktalk, SmallValet, Valetalk, ValetST,
> NorayTalk, Ballard, Noray and Cruise. Please let us know which one is your
> favourite or help us find a new one.
>
> Another important subject is the team. There will be three "mentors",
> Esteban Lorenzano, Diogenes Moreira and myself, Mariano Martinez Peck; and
> three students: Guillermo Polito, Nicolas Scarcella and Santiago Bragagnolo.
>
> We are open to suggestions and ideas. In addition, we have defined a
> possible list of actions that I copy at the end of the email.
>
> For the moment, the url remains www.squeakdbx.org and the mailing
> list squeakdbx at lists.squeakfoundation.org
>
> Once again, we want to thank ESUG for their support and trust.
>
> Thank you very much,
>
> SqueakDBX team
>
>
>
>
>
> Possible list of actions:
>
> 1) Change SqueakDBX’s name.
>
> 2) Update GLORP version since the actual one is 3 years old.
>
> Port it again from VisualWorks, create a VW porting tool (may be).
> Complete support to Glorp.  Today it works with PostgreSQL, Oracle and
> MySQL.  Make it work with most databases OpenDBX supports.
>
> 3) Create a lightweight solution, alternatively to GLORP.  There are some
> options:
>
> Make SqueakSave work with SqueakDBX.  SqueakSave developers already
> contacted us because they wanted to do it. SqueakSave seems to be 20% slower
> than Glorp but you don't need to write the mappings :)
> Adapt Ramon Leon's active record to use an abstract database driver, and
> create a driver for SqueakDBX.
> Port the new Glorp’s kind of active record to Pharo. (included in 2).
>
> 4) Write a Pharo By Example 2 chapter based on the card game Stef built ;).
>
> 5) Cog compatibility.
>
> 6) Use Alien instead of FFI.
> Eliot is working on a threaded CogVM. One of the projects of the GSoC of
> this year was to make something similar to a threaded FFI. What the student
> did is a modification in Alien (I think) that can be run in a multithreaded
> envirorment. He worked with Eliot. The idea is when Eliot releases the
> threaded CogVM, this FFI would work our of the box, and would avoid locking
> the WHOLE vm while a C function is being invoked (as it happens today with
> FFI).....So....when that VM is released, we MUST migrate to that).
>
> 7) Explore performance issues (maybe with our approach of "In thread
> execution plugin").
>
> 8) Complete integration with OpenDBX. For example, Oracle, for large objects
> (Clob, Blob, etc) use specific functions. There are specific functions in
> OpenDBX that have to be used if the database uses specific functions (oracle
> is the only one for the moment.). We don't manage those functions yet.
>
> 9) In this link http://www.squeakdbx.org/Targets%20and%20Features
> You can see a list of future possible features like Connection pooling (now
> it is done!), Prepared statement interface, Store procedures, Escape and
> avoid of SQL insertion, Authentication support: extends to other methods,
> not only user/password, Full text support, etc.
>
>
>