3 ms·

> Does the image approach mean that Smalltalk is not really suitable for quick and dirty sys admin type scripts that you would use Perl or Ruby for? No, it's n

> Does the image approach mean that Smalltalk is not really suitable for quick and dirty sys admin type scripts that you would use Perl or Ruby for? No, it's not, but that's what we have Ruby for. :-) > would it be technically feasible to have a different Smalltalk image for every single account that is loaded only when that account is being used, with basically all the account data inside the image? I think that that is how DabbleDB works today. They have a different image for every account. Avi's post from March about how Gemstone works has a good overview of things: http://www.avibryant.com/2008/03/ive-had-a-numbe.html http://www.avibryant.com/2008/03/ive-had-a-numbe.html

gnaritas 18y ago
I've spoken to Avi and that's exactly how DabbleDB works. He front ends the system with Apache and uses a rewrite map to launch an external Ruby script that checks to see if the image for that request is running. If it is, it returns the port its running on, if it's not, it launches the image, records what port it's on and and proxies the request to it. Images time out after X amount of time and shut down on their own. Each customer gets his own image, though the customers data is stored outside the image using an image segment. This lets them upgrade the Dabble image without messing with the customers data. When an image fires up, it loads up any image segments into it. Basecamp is also exactly the kind of app that fits well with this architecture. Lot's of small independent databases. It's not that different from how Hacker News uses load-table to store the customer data in files and loads everything into ram when the web server starts up. Both systems are basically homebrew object databases very well for the limited load placed on them. Gemstone is the granddaddy ODB that can handle anything you can throw at it.
- richcollins 18y ago
  http://seaside.gemstone.com/docs/GLASS-Announcement.htm http://seaside.gemstone.com/docs/GLASS-Announcement.htm Unfortunately, it isn't FOSS.

gnaritas 18y ago

I've spoken to Avi and that's exactly how DabbleDB works. He front ends the system with Apache and uses a rewrite map to launch an external Ruby script that checks to see if the image for that request is running. If it is, it returns the port its running on, if it's not, it launches the image, records what port it's on and and proxies the request to it. Images time out after X amount of time and shut down on their own. Each customer gets his own image, though the customers data is stored outside the image using an image segment. This lets them upgrade the Dabble image without messing with the customers data. When an image fires up, it loads up any image segments into it. Basecamp is also exactly the kind of app that fits well with this architecture. Lot's of small independent databases. It's not that different from how Hacker News uses load-table to store the customer data in files and loads everything into ram when the web server starts up. Both systems are basically homebrew object databases very well for the limited load placed on them. Gemstone is the granddaddy ODB that can handle anything you can throw at it.

richcollins 18y ago
http://seaside.gemstone.com/docs/GLASS-Announcement.htm http://seaside.gemstone.com/docs/GLASS-Announcement.htm Unfortunately, it isn't FOSS.