Sebastian, this is a neat idea could you give just a little bit more detail on how the objects are mapped into the SQL database? I can only guess that you mean that they are somehow chunked into blobs and persisted.
]{evin
Sebastian Sastre wrote:
But an image can be scaled in a farm of servers. A persistent Smalltalk can have valuable objects transparently stored in a shareable support. I've implemented in Squeak a *proof of concept* of this idea in a system that can store in a relational database the objects without having to map classes to tables. It uses the same intention that the VM uses to store objects in RAM. It uses the RDBMS as if it where an analogy of the RAM. I based the design on the blue book. The idea is not original Sun has played with something like this for Java.
Every instar value you change in an object is made ACIDly. Is slow because the support is slow. Write and read barriers can help a lot. Concurrency also should be managed.
But you can make a really big image with this by scaling it as much as PostgreSQL can scale.
Cheers,
Sebastian Sastre
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Marcel Weiher Enviado el: Miércoles, 29 de Agosto de 2007 20:51 Para: The general-purpose Squeak developers list Asunto: Re: pipe
On Aug 26, 2007, at 3:10 AM, Fabio Filasieno wrote:
Smalltalk is very different - you always can add behaviour
you need
to the other object and the application logic is
distributed across
the system.
That's not the point, but you are right, Unix and Smalltalk are different. In regard to the black boxes thing.
I think a lot of the differences are superficial, but one seems very deep: Unix's unifying principle is extensional, Smalltalk intensional.
That is, Unix gets its power from the fact that everything is just represented as bytes, and you can pipe those around. Who cares what they mean? To the refined tastes of us Smalltalkers that seems barbaric, but it is very powerful in a very pragmatic sort of way, and gets you extremely loose coupling and late binding (of things other than the fact that it's all just bytes). Of course, you lose moving to higher levels of abstraction, and no, XML doesn't really do it.
Smalltalk, on the other hand, does really well with modelling semantics, as objects sending messages, but has a hard time extending its unifying principle outside the image. Which is somewhat ironic considering the idea was connecting things and late, late binding.
Marcel