Here's what I can tell you from developing AJAX apps and working with companies that are trying to build tools to develop AJAX apps:
1) The fact that you can hack RR is a big plus. It makes bootstrapping much easier. 2) Parsing tools: Chunk Expression and Regular Expression support are also big plusses. 3) The hardest part of developing AJAX apps (or FJAX, or whatever flavor you prefer) isn't building the framework (hell, you don't even need to if you want to use Prototype, Dojo, etc.). The hardest part is accurately representing what you want your application to do and mean using XML so that the application works inside of the framework. Obviously a hackable environment that has crazy-helpful parsing tools make life a zillion times easier. 4) Application server: Big problem. If RR were easier to multi-thread this would be much easier, but it isn't yet. 5) Database server: Problem. While RR can perform database tasks fairly easily due to the paradigm, it is more difficult to make that model scale. On the good news side there are database plugins, which would help to separate the database server and the application server, but that adds overhead which is clearly a drawback. 6) Paradigm paralysis: Big problem. It would probably be better for RR to try to dump the card/stack vocabulary at this point and try to look more like a database. Explaining RR's design to a noob is a bit challenging. When HC came out, everybody knew what rolodexes and recipe boxes were. Now...not so much. 7) Implicit typing: I think this is actually a positive. It makes conversion to JS much simpler than if the language was strongly typed. 8) Message path, event handling: Neutral: Some of this can be coded into the framework, but some of it is going to have to be dealt with in the Application Server. The bad news is that this will require more network overhead. The good news is that you can do things that are difficult to do otherwise. However, I would think that it would be better to push as much of this up into the framework as possible. If the application server is compiled, then this shouldn't be too much of an issue as the message path can be made static at compile-time, except for some "send" and "pass" messages, which will have to be handled in the back-end 9) Security: Neutral - At this point injection is a limited risk, and it is possible to ensure that when RR receives messages from the client that it doesn't take them as valid on their face. The fact that RR is hackable means that we can accomplish this goal without a bunch of intervention by the developer. On the downside, the inability to intercept commands in the message path means that we cannot stop stupid message-injection-hacks like Dukakis as easily as we did with HC. Did I miss something? -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
