why not keep the database stupid?
Dmitri raised an interesting point--why not keep the application logic out of the database? Until now I'd been thinking of COODBMS as an OODBMS, so ofcourse I was thinking that the application logic should be in the database. But what if we make COODBMS dumb backend and put application processes in front of it?
The advantage of having a single process is speed, of course. But that is not always the most pressing concern. Having application processors means we can spread the system over multiple machines for greater scalability. It also means that application bugs will be [largely] confined to the application server--a good thing.
Now for Aye, we need to add notifications so that Aye can maintain its own cache. Why not then focus on notifications and a cache implementation next?
posted by Bill la Forge @ 10:16 AM
2 comments
2 Comments:
Additional thought. Norm always wanted this work done in Python, as then we can put python script in a Descriptor Entry. So we can write the application server in Python and that will give us access to a REAL scripting language.
One complication is that the database maintains the transactions. But lets consider putting the application server over rather than in front of the database.
Now a request comes in and it requires the evaluation of a Python script. the request is sent to the application server, within the context of a transaction, and the app server evaluates it and returns a response, accessing and updating the database in the process.
Hmm. Sounds more like a language server now than an application server. And we could always do this later--being able to process Pythin scripts is an interesting capability. But now I'm back to defining Roles for Rolons and attaching scripts as DEnts.
Post a Comment
<< Home