On 10 Nov 2005, at 18:50, Dan Shafer wrote:
Once again, your view is limited to what now is rather than to what can and will emerge. Software is an ecosystem. Today, if you took your blogging tool and made an AJAX version, you might well see yourself being forced to create a massive and expensive network/ server infrastructure. But you might not. Mirrored sites, a mesh of cooperative servers run by a third party supplier, rented space on a large server farm with on-demand capacity...there are dozens of possible solutions to the problem.
To put it another way - it is about the price of code reuse. Setting up a web service and getting many apps around the world to use this web service is becoming very cheap. Think of running a Rev app on your ADSL line of the future. Think how much easier it is to maintain and support such a service without having to deal with installation problems - Magic Carpet or no magic carpet. Think of how much flexibility you give your end customers when they can use Rev front ends to layout and process the results of these web services how they see fit. The unintended uses of the web service....
It is not either web service + thin client - it is how web services will change the relationship.
What I'm trying to do here is to get the Rev community to think outside the desktop application box into which it fits so neatly because it is my considered opinion, based on more than three decades of experience in technology assessment and analysis, that the box is rapidly disappearing. I don't want us to abandon Rev; I want us to figure out new things we can do with Rev -- or get RunRev to add to or change about Rev -- that will allow it to play a premier role in the changing marketplace.
Dan -I agree with you 100% here. It is important that we understand this change and give RunRev enough time to plan this into their strategy - else many developers will have to move over to other toolkits that do take such a path.
For a simple example: the best-of-breed AJAX developer's toolkit could and perhaps should be written in Rev. Server-side Rev componentry to support AJAX would be another great opportunity. There are several such large gems lying on the ground waiting for someone to pick them up and run with them.
If you take a look at AJAX technology frameworks such as Ruby on Rails - you will see how easy it is to add a web service which simply does the job of replacing a <div> tag with a piece of HTML. If this web service returns htmlText = xHTML then we can just place it in a field in Rev.
What does this mean? It means a small Rev based team (I am the only one here) can work with open source web developers and create great interfaces and faster development than any web designer (unless you get too flash with your interfaces :)
What else does this mean? You can sell your strategy with Rev. Throw away the marketing hype regarding AJAX (though you can use it if you want :) - the real point is you can tell your client - "this is quicker and more powerful) to develop the GUI in Revolution :) - but once done this acts as a spec for creating truly great AJAX web sites! Ultimate AJAX client prototyping. Of course the client will rarely want the inferior AJAX interfaces once they are hooked on the Rev interfaces - but they have a path for zero install scalability which is clear and cheap.
More - what does it mean for the choice of programming language? At the moment in the era of monolithic web applications - you go one way - choose your language - perl, php, python, java... then get your team and implement. How many times has this cut out smaller languages such as Rev from the picture - not enough developers.
Now Rev developers can be a meaningful part of that team. The risk has been removed for the client - they know they can switch to AJAX and browser delivery if RunRev fold.
When I discovered Rev and then quickly discovered how minuscule its audience was, I was discouraged at the same time I was encouraged. I was discouraged because I feared Rev would go the way of so many other great technologies whose companies couldn't sustain them through slow-growth periods. I no longer worry much about that. I was encouraged because if only a small number of people "get" Rev, my competitive landscape is uncluttered and accessible. The same is true for AJAX except there's no need for a single company to be involved in any meaningful way
As an example here with the TV project i am working on - I have some perl programmers working on web services related to LDAP, some php programmers working on XML based services (for some reason there were more of them available), and Java developers working on the financial crypto stuff - most all of these projects are open source. For the client develop the interfaces in Rev - the interfaces layout the resulting fragments of text or xHTML. Now how would I get the same number Rev programmers? Would i be able to use the existing range of high quality modules that you find in CPAN if I did? Would the client have accepted this "risky" strategy?
I'm thinking on this too - the TV project will need a good web site next year with much of the functionality we have with the Rev interfaces. So maybe this site will use Ruby on Rails to integrate the pieces for the web. Maybe it is possible to have Rev running on the server side so that I can reuse the client side code developed in this first phase? Maybe I can use Rev to deliver the image processing aspect of the project - beats image magic any time.
How Rev fits into this new picture is VERY important. It is much more than AJAX or not. It is also about frameworks - that is Ruby on Rails makes it super easy by setting up "scaffolds" for various types of web app - Rev with a good code library of python, ruby, or whatever would make the ultimate "scaffold" generator. It is also about structure - model, view controller (MVC) - which most of us who spend any time developing in Rev naturally migrate to to organise our work. But Rev needs this structure built in - not forced, just the right defaults.
The pieces are all there - the opportunity is now - the question is whether "we get it" or we "miss it". Not everything that is new is bad.
Don't believe the hype - I know Dan does not. _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
