[SqueakDBX] About ports

[Mariano Martinez Peck]

Hi folks: There is some interest in porting SqueakDBX to different
Smalltalks. Jan Vrany wants to port it to Smalltalk/X and Marcelo Cortez to
Dolphin. So, the idea is to discuss here the necessary things I should
modify so that this task is easier for you.

I have been talking with Jan in ESUG and he found a couple of things I
should do. In addition, I already did the stable release, so I can break
whatever I want :)

About the code, I will do these things:

1) Create the abstract class SqueakDBXSmalltalkDialect with all of the
messages like self subclassResponsibility. This class will be in the core.

2) Create a package in my monticello repo called SqueakDBX-Dialect-Squeak
and I will create there the class SqueakDBXSqueakDialect (subclass of
SqueakDBXSmalltalkDialect ) . Now, for Squeak and Pharo users they will need
not only the core, but also this package. If you want to put here packages
like SqueakDBX-Dialect-SmalltalkX or SqueakDBX-Dialect-Dolphin, there is no
problem. But I don't know if this is useful for you.

3) FFI calls. This is dialect dependent, but the current design is perfect
for this :)
I will keep the class abstract class OpenDBX  in the core and that will be
the API. As you can see there are all the messages with a  self
subclassResponsibility. I will then move my current subclasses of OpenDBX to
the package SqueakDBX-Dialect-Squeak.
Then, what you should to in your dialects is to create a subclass of it and
use that. See the message OpenDBX class>>ffiImplementationForOS

4) WeakRegistry and GC: As you may know, we keep the connections in the
WeakRegistry so that we can release the database connection when the GC
collects a DBXConnection object.
But this, again, is dialect dependent. So, the piece of code that was doing
this, now it will delegate to the current SqueakDBXSmalltalkDialect
subclass. In my case it will be SqueakDBXSqueakDialect but in your case it
will be other.

5) Now, all the things that are dialect specific should be in
SqueakDBXSmalltalkDialect and subclasses.

6) The core is thought in an ANSI Smalltalk. So, it will be difficult if for
every message or class you don't have in your dialect I have to change
something. That would be part of the port work :)   Anyway, we can discuss
each of these situations and evaluate what to do.


Now, about the procedure, as I talk with Marcelo, I think the best way to do
this is to do something like TDD:

- First you port the tests
- You port the rests of the things until the tests are green :)

What do you think about this?

Best,

Mariano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeakdbx/attachments/20091006/11d4b37d/attachment.htm