Can Rev be used as server database?

[revolution at knowledgeworks.plus.com]

Hi Alex,

I think that any of the xTalk/Hypercard-based models already have much of what is offered by ZODB.  The Zope object database is just a way of saving in-memory objects to a persistent data store.  As I understand it (in principle), ZODB is just an database for objects, written in Python, and capable of persisting Python data structures.  Really, a stack is just the same thing, only for xTalk.  

To me the xTalk way is far more acceptable (and I prefer xTalk to Python).  For me it is much easier to get a grasp of fields, cards and stacks than the objects that get packed away into the ZODB...

Having said all that, I don't want to belittle Zope.  It is a fantastic concept, and is probably on a par with J2EE and .Net as an object-oriented web application framework (I just hope that Apple are going to publicly re-market WebObjects, but I doubt it).  Given that Zope is open-source, not backed by Microsoft or Sun (nor Oracle, IBM, etc.), and that it is based on a scripting language, it is very impressive... OK, maybe it lacks the kinds of transactional complexity 'required' by 'enterprise' frameworks... (scare quotes intended.)

But I will be totally dumbfounded if the Rev/MC users come up with anything like it.  

However, there is no getting over the fact that Python doesn't even have a true IDE (don't talk to me about Wing), and Zope has to be programmed through a browser interface... browsers are a poor interface for users, so they are definitely are a poor interface for developers.  Moreover, the Zope project seems to be in perpetual flux with DTML, Plone, ZPT...

I looked at Zope long and hard, bought every book available, and gave up on it...

I'm heavily involved in web application platforms at the moment, and would love it if I could use Transcript rather than the panoply of solutions I am using.  Most of them are overkill for what is in principle actually quite straightforward.

I would love to see something like Zope, but using Transcript, and with a proper IDE (even the Metacard IDE is light years ahead of what is used for Zope)....

I really have little idea of what Transcript might be capable of vis a vis web applications.  (I've followed Pierre's work on the Metacard list, and it sounds quite amazing.)  

I'm using a lot of Java, but solely because I can use it to integrate diverse platforms.  

I have some idea that the principle limitation of the Rev engine in a multi-user environment is that it is not capable of threading.  To me that means that any new HTTP request is beholden on the previous request(s) having been dealt with in a timely manner.  Of course, most of us do not really want to get involved in multi-threaded programming (as I believe Scott Raney as pointed out in the past).  Nevertheless, given the present engine, I think it is a bit optimistic to rely on the speed of the engine to save us from surviving being slashdotted...  Most web users get frustrated if they have to wait more than a few seconds, and, yes, memory-resident data stores can be very fast...

I think that given adequate mechanisms for communication and data exchange the server-side data store is mostly irrelevant.  It is just a data store and there are many alternatives.  

Don't get me wrong. I think that for user-centric apps, Rev is the bees-knees (including web-awere, user-centric apps -- ok, REBOL and a couple of models are also pretty cool in that regard, but they aren't as elegant as Transcript, they don't have the genealogy of xTalk and Metacard, and they have really obscure[=costly?] licensing).  

IMHO this is where Runrev need to focus.  They really, REALLY need to see Revolution as a replacement for Java applets, Flash, REBOL, even replacing browsers as the UI for web apps.  This has barely been scratched by Richard's GoRevNet, as impressive as that is.

Just my tuppenceworth... I think many people here know considerably more than I do - I spend way too much time looking at non-Rev platforms!  So, I will be delighted to be corrected :-)

Regards
Bernard 

>>
To really take it to the next level, I would recommend modeling it 
after ZOPE and ZODB. Zope is a web application platform built on 
Python, and it is layered upon ZODB, Z Object Database. So Zope is a 
web-aware, multiuser, multithreaded, transactional object persistence 
platform
<<