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
<<  


_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to