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