Update:
Socinian writes in a comment...
[An image is] just not a multi-user database. Make every image multi-user and every running image a server and Smalltalk will soar. Think in terms of the Chandler project. Everyone's a producer, consumer, and database.Essentially Gemstone/S is a highly scalable, distributed multi-user "image". (And a good bit more.) No doubt there is a lot of value in this concept. But the concurrency complications go way up as well. Maybe the simplest form of this idea is a Smalltalk implementation of Prevayler.
Original:
Ian Bicking writes in a comment on Avi Bryant's blog...
To me, the image seems very challenging from a usability point of view. Images are monolithic, while most version control systems work on filesystems which are rather distributed. You can have two branches or checkouts sitting along side each other, and tools can access either just fine, compare, contrast, etc. In Smalltalk that's two discrete systems. Maybe if you could run select code in a specific branch, while the rest of the system remained in a different branch. But that seems infeasible, and even if it wasn't, since it's utterly inconcrete it's also rather opaque.Smalltalk-80 was designed to put the tools and the objects they evolve into one image. ANSI Smalltalk was designed to support a "firewall" if desired between the tools and the objects they evolve.
Either way, I think it is not helpful to combine discussions of "the image" too closely with discussions about "version control". Smalltalk version control is typically done independent of the image. The image is where specific versions of things are installed to provide specific executable capabilties (e.g. an application). Various images can have various versions of various things installed in them.
That said, an image *can* contain things which "do version control" and often the things they version are things in that same image. But "the image" and "version control" are really independent things.
Since there can be many images, let's not talk about "the image". Better to think about images as simple, yet powerful object-oriented databases.
Things in an image can be made from specific versions of things that originate in some version control system, just as things in a Zope Object Database can be made from specific versions of things that originate in some version control system.
What if a Zope Object Database were even easier to use than it already is? What if you just had one ready by default and your application was automatically a part of the database, and all your favorite tools were automatically able to inspect and update that database?
That's kind of what should come to mind when thinking about "the image".
2 comments:
What if you just had one ready by default and your application was automatically a part of the database, and all your favorite tools were automatically able to inspect and update that database?It's just not a multi-user database. Make every image multi-user and every running image a server and Smalltalk will soar. Think in terms of the Chandler project. Everyone's a producer, consumer, and database.
Socinian: The ZODB is client/server when you use ZEO, so it is potentially multi-user. The ZODB had all the features Chandler would need, but they decided against it for other reasons (e.g., language-neutrality, and a more strict schema).
That said, invoking the ZODB is no way to convince me of the benefit of anything ;) *Especially* the idea of keeping code in the ZODB. I know that pain, I do not care for it. I think that's the growing consensus among Zope developer; see this: http://plope.com/Members/chrism/zope_collab Also note that Zope 3 encourages most code to be in the file system, and that's a design done by someone who doesn't care for a relational database (Jim Fulton), and it's not meant to phase out the ZODB. Admittedly, Smalltalkers have taken the image to places the ZODB never went, but they also are actively choosing not to follow Smalltalk. The ZODB had versioning too, BTW, and it was horrible (though again, I'm sure Smalltalk image version control is better).
BTW, I posted again to that thread, wandering on to other topics. I blame my long comments on my blog software being broken. Note: I blame that on metakit, another non-relational database. When my subversion repository breaks, I blame it on Berkeley DB. Haha! RDBMSs and flat files are the two true ways, because they are somewhat less broken than other things!
The link to the blog seems to be broken (something's funky with their links); this should work: http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3279248343
Post a Comment