The Disappearing Desktop - It's Real This Time

[David Bovill]

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.