Hi Alex, Thanks for the comments. It is helping me to think things through.
>> I do not think people should be prevented from using Rev on the server side, for lack of documentation or supporting. << I agree. I too wish that the documentation on CGI programming with Rev was more pronounced. However, so much of the industry is moving against CGI (because of process forking)... maybe it is an unnecessary move against CGI, given Moore's Law. Maybe Pierre will chip in and tell us how feasible it really is. Whilst there are things that can be learnt from Zope (and other open source projects), I think it would be a massive task for Rev users to try to reproduce something like that. For me, I would prefer to use one of the many available multi-user databases than try to build it all with Rev. The same goes for the many different web application frameworks (having said that, I just spent several months building my own...) For me the incredible potential of Rev is at the front end. When you say that custom properties are fast, isn't it just the case that they are fast relative to working with data that is in fields in stacks? Is there really any speed comparison that shows they are faster than in-memory data structures in other languages? (I would love to be shown that data can be loaded and manipulated with custom properties much faster than with the in-memory data structures of other languages). With regard to XML ... It is cool to have an XML parser in Rev. But the potential is vast, and I hope to see some sign that Runrev have a strategic direction with this. For example, it would be nice for them to integrate version control from within Rev. This surely must be of use to _all_ Rev developers. And since CVS seems to be coming the standard and is open source, I see no reason why something like Geoff's XML stack couldn't be fully integrated into Rev along with a CVS module. That way one could just convert a stack into human readable XML, store it in the CVS repository, and reconvert it back into a stack. Furthermore, we could perform diffs on this so that we could see what had changed between two versions, etc. Even if Runrev do not want the hassle of integrating with CVS, it would be beneficial if stacks could actually be emitted as XML to the filesystem so they could be diffed. As it is, it looks like XML support was included, but that there is no strategic direction on this. Other platforms were at this level of XML integration 3 or more years ago. Maybe with the further integration of Metacard and Runrev we will see more of their strategic vision. Anyway, these proved to be a very pleasant and thoughtful afternoon :-) Regards Bernard _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
