Hola: Existia una ODBTalk creo no? era el de Visual Smalltalk? Por ODBC creo que era, algo asi. Por ahi podria ser DBxTalk otra variante.
Saludos 2011/3/5 Mariano Martinez Peck <[email protected]>: > > > On Fri, Mar 4, 2011 at 1:48 PM, Esteban A. Maringolo <[email protected]> > wrote: >> >> Muy bueno muchachos! >> >> Como no me gusta ninguno de los nombres que sugieren, les sugiero otro: >> DBTalk. >> > > jejejejejej ta bien...gracias por la idea. Vamos que ver que elegimos > finalmente,, > >> >> Saludos! >> >> Esteban A. Maringolo >> >> >> >> 2011/3/4 Mariano Martinez Peck <[email protected]>: >> > >> > >> > ---------- Forwarded message ---------- >> > From: Mariano Martinez Peck <[email protected]> >> > Date: Fri, Mar 4, 2011 at 9:40 AM >> > Subject: [ANN] ESUG supports once again SqueakDBX >> > To: Pharo Development <[email protected]> >> > Cc: ESUG Mailing list <[email protected]>, The general-purpose >> > Squeak >> > developers list <[email protected]>, A friendly >> > place >> > where any question about pharo is welcome >> > <[email protected]> >> > >> > >> > 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 [email protected] >> > >> > 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. >> > >> > -- >> > To post to this group, send email to [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
