Can Rev be used as server database?

[revolution at knowledgeworks.plus.com]

(Sorry folks, this is a long and rambling post...)

Hi Alex,

I suppose the vital issue for a mulit-user, server-side database is going to be concurrency - does it look to users that they are getting the immediate attention of the server, or are they left hanging around?  Moreover, can these apparently independent users update the database simultaneously without corrupting the data?  

Obviously even with threading, this is really a bit of a trick - because of processor speed, threading, I/O speed, etc.. the user should get the impression they are not in a queue.  But there are many technological issues to overcome for Rev to be able to provide this effect.

Clearly, if one has enough speed in the Rev engine and the server processor, and the IO requests do not slow things down, then the user can get the impression that they are the only one being served.

To some extent this is what happens with the use of MySQL on db-backed web sites - given the table structures used in MySQL, along with the stripped-down SQL conformance, it is fast enough to give the appearance of concurrency.  No request is blocking any other, or at least not to any user-perceptible degree.  Last time I looked at these debates, MySQL was using table-level locking, and relying on the speed of the db engine and the read-intensive nature of the web applications to prevent users noticing this.

If I remember rightly, it was this kind of reliance on speed (and forking of processors) that Pierre was using to have Rev acting as the CGI engine to a PostgreSQL db.  Normally people recommend against CGI becuase of the overhead of forking, but his scenario seems to run against this wisdom and yet be successful.  Nevertheless, by forking processes the engine is getting a kind of threading.

Another way to give users the impression of concurrency is to use in-memory databases, such that the IO delays are reduced.  This is one way that Rev already has an architectural advantage (although RDBMS also mimic this to some extent via caching).

But Rev dbs will need to be written to disk to prevent data loss in the event of a crash.

Furthermore, there is the whole issue of locking for writes to the database.  I'm not sure if the Serendipity db has any locking mechanism.  Without some kind of locking or versioning mechanism, I don't see how one can have a multiuser database.

To my way of thinking, it is better to exploit some of the freely available, tried and tested relational databases.  I recommended that Runrev look at closer integration with Firebird about a year ago, but nothing has come of it.  The technology in Firebird has been around for 20 years, so it is well-tested.  It is very highly conformant with SQL 92 (as high as all the mainstream dbs from big vendors).  Yet it also has a tiny footprint, so can be embedded with standalone applications. Oh yes, and it is multiplatform (win32, unix, os x, linux).   Last week I also drew the lists attention to SQLite (but there seemed to be little interest in this.)

I don't see any benefit from Rev users or Runrev re-inventing the wheel.  

Now, on to Zope :-)

The Zope framework is about publishing Zope objects to the web, and the ZODB is just a place to store these objects persistently.  However, Zope can also use various other storage facilities (relational dbs, filesystems, LDAP).

There are many great things in this framework - such as extensive security delegation, acquisition and DHTML at the most basic level, and Zope Page Templates and Products at a higher level.  Now, maybe this kind of framework could be implemented in Rev, but... these frameworks would require a lot of work to architect and built and maintain, and would require a lot of work to be usable by others.  This is one of the problems with using Zope.  The Zopistas make a big thing of when someone 'groks' [= 'comprehends'] Zope.  It requires a mind-shift, that could take several months of immersion in the product to acquire.

Now, Zope is backed by the Zope Corporation.  I've no idea of the size of it, but it is at least dedicated to very clear objectives: developing and maintaining the Zope product, and consultancy services to implement this product (where most of their revenue comes from).  I don't think that Zope would have survived if it wasn't open source.  And it is supported by quite an extensive army of Python developers.  And yet still most people in IT have never heard of Zope.

The real strength of what is going on with something like Zope is that it provides a framework for the architecture of dynamic websites (inheritance, authentication, persistence, componentization, etc).  I don't think this is the kind of thing one wants to build into Rev, nor build with Rev.  Not that it can't be done, but it is a huge undertaking to do it, and a huge undertaking for anyone to commit to using it.

I agree totally with the idea of greater integration of Rev with web standards and technologies, but I don't think that the aim should be on server-side processing.  I mentioned this also on the list recently, but was met by a fairly dead silence.  I asked what Runrev's plans for XML were, and pointed out that it seemed to be a bit unclear as to the purpose of including XML functionality in the latest version.  Geoff Canyon responded to say he has a stack that can transform a Rev app to XML and can transform XML to Rev.  But it doesn't work with Rev 2, so as far as I can see, they still don't have any clear plan for XML integration.

IIRC, the altBrowser is IE only?  I would not like to rely on Microsoft for anything.  They have a history of destroying competition (by fair means or foul).  And it is my belief that we have seen nothing yet: they are going to tighten their monopoly position in ways that many people have not yet imagined.

If Runrev is going to become more closely integrated with a browser, then I would strongly suggest that people consider the Gecko rendering engine from the Mozilla project.  Yes, I know that the Mozilla browser can be a bit of a sloth compared to IE (although I don't think they are that different - I've seen IE take up to 100mb of RAM on my laptop...yep, 100mb!)  I'm unclear as to how big a task it might be to employ Gecko.  I suspect that MS make it relatively easy to integrate IE (people behind the Mozilla project just didn't get it, until Apple snubbed them with Safari).

I don't think one should get hung up on web browsers as a platform.  They are a joke.  Try developing quite simple CSS that work in IE6 on XP, then view them in IE on OS X and see them not work.  Same applies to Netscape and Mozilla.  Same applies to Javascript.  

Why is replacing Java applets or Flash over-optimistic?  [If you ask me, the whole idea of downloading Java applets was wildly more optimistic than my suggestion :-)]  If it can done by Sun and Macromedia, it can be done by RunRev!  OK, Runrev is orders of magnitude smaller...

So what is required?
a) integration with web technology (especially XML)
b) trust (certification) and/or a local security sandbox.

These are both achievable (and probably in many different ways), and I think the market potential is phenomenal.   

What I am interested in is the idea of distributed applications built using Rev.  The web technologies serve to integrate the Rev apps with server-side data stores and processing.  If this runs in a browser, all the better.  There are other companies out there right now doing this.  As far as I can see, the only thing stopping them is their low profile and their high or obscure licensing costs. (Oh yes, and a few are tied to IE).

But I don't see that Runrev recognize the potential.  And I'm starting to think it's just you and me talking :-)  Rev is the best RAD tool I've seen for generating client apps.  But I think we are inexorably moving to a connected world, and it will be the distributed apps that have the greatest potential.  I would like to see Runrev move into this area and dominate it.  I think REBOL is dying (sad to say) - they have just open-sourced parts of it, and since this was not something they were prepared to do before in their (relatively long) history, I think that is symptomatic of their problems. 

My vision is to be able to rapidly develop and deploy lightweight applications to multiple platforms.  They should be capable of securely retrieving and storing their data on central repositories.  They should have fantastically creative GUIs [I would have to employ a designer for that ;-)]  They should be very responsive. They should be dynamically reconfigurable - if I make a central change, the applications would all be capable of re-writing that part of themself when they re-connect.

I think Revolution is already capable of 95% of this.  And I don't see anything that comes close to this vision (except REBOL).  

I want to be able to use Rev as I have described above within the next 6 to 12 months.  My Java projects will keep me busy until then.  If I can't do these things with Rev then I shall have to re-consider the alternatives.  But with the alternatives I will lose things like platform independence.

My apologies for such a lengthy post...

Regards
Bernard.

>>
How about the Rev IDE can be used, and Revolution cards can somehow 
represent themselves via HTTP as XML, or as HTML + CSS!
[snip]
I agree- but replacing Java Applets or Flash is overly optimistic isn't 
it. Since there is no browser plugin for Revolution, we'll just have to 
do the converse and embed the browser into our apps with altBrowser!

Alex Rice, Software Developer
<<