> 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@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.
>
>
>