Revolution Web Browser Plugin

Luis luis at anachreon.co.uk
Thu Nov 2 07:45:48 EST 2006


Hiya Mr Rev Server maker,

Andre Garzia wrote:
> Luis and friends,
> 
> well, this topic has been touched before. Many times. :-)

I suppose that indicates it's need... ;)

> 
> I'll touch simple things first, the stacks and cards metaphor of 
> Revolution can be presented in a XML format, but anyway, anything can be 
> represented in XML format. XML cannot contain binary data, this is a 
> violation of the spec. You binary data must be encoded with base64 or 
> some other encoding. Not all browsers support SVG also.

XML being pretty much 'freeform' when it comes to tags, the spec could 
easily be tailored for internal use, such as enclosing binary data. For 
internal use this doesn't seem bad to me: You see something good and you 
make it work for your situation.
Now, it 'appears' to be binary data (I believe someone indicated this 
also) but it could be anything else encoded in there.

True, not all browsers support SVG, but there are plugins available.

> 
> My systems as seen in http://www.andregarzia.com are not ready, and they 
> are targeted at developing web applications with a HTML interface and 
> web services using REST and XML-RPC.
> 
> As for the eternal struggle of those in favor of a web plugin, let us 
> think one thing first. Web plugins are not magical, people still have to 
> download and install the plugin, this is not automatical. The plugin 
> would at least weight as much as the engine, so it is actually the same 
> thing as downloading a Revolution stack player. Plugins must be built 
> not only for each browser because each uses a different interface but 
> also for each platform. I don't think a browser plugin is a wise idea, 
> there's not enough resources to mantain it. I think there are only two 
> ways to go:
> 
>     1) Use thin clients. Many enterprizes are moving away from the 
> browser. The browser is dumb and you spend a lot more time dealing with 
> its shortcomings than coding your own solution. I advise people to read 
> the "beyond the browser" article by Richard Gaskin.
>     2) In case you really need the browser, use XHTML + Ajax techniques. 
> This needs not a plugin, you can just code it server side with Rev and 
> client side with Javascript.

Yep, I prefer thin clients, but flexibility of choice is what I'm 
thinking of. You still have to download a thin client!
The ability to do this within Rev, having a Rev card as a 'web page' 
would be a neat trick, and might answer a few needs.

> 
> A thing that could be done is to make the engine output java bytecode, 
> this would allow a stack to be run inside JVM which would bring it to 
> the browser arena, but again, this would involve rewritting the whole 
> engine and debugging the new engine and also the JVM, again, there's no 
> resource for that I think, it's RunRev not Microsoft.

Yeah, that would be a task and a half! Mind you, I'm curious as to what 
approach to the VM, if it is a VM, RunRev uses.

Cheers,

Luis.


> 
> Andre
> 
> 
> 
> 
> On Nov 1, 2006, at 9:14 AM, Luis wrote:
> 
>> Well, from a while ago the XML nature of the Cards was bandied about.
>> I would have through these could be parsed and the appropriate 'web 
>> equivalent' controls then written to an HTML file, precluding the need 
>> for a plugin.
>> A running Rev instance could do this to itself, saving off the 
>> contents of the Card view. Stuff like buttons should be ok as long as 
>> they are 'web safe' images, then there's SVG too.
>>
>> Interaction would need cgi processing for the data to be sent back to 
>> the running app, or dealing with it within a Rev Web Server: 
>> http://www.andregarzia.com/revwiki/page/RevOnRockets
>>
>> The only problem is the embedded binary data: Are there docs that 
>> detail its structure?
>>
>> Cheers,
>>
>> Luis.
>>
>>
>>
>> Viktoras Didziulis wrote:
>>> Revolution applets, with possibility to communicate with web page via
>>> javascript or revscript on a web page would be a very handy solution to
>>> deliver java-like applets without all the complexity and overheads of 
>>> java
>>> language. I vote for this.  Best Viktoras
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 



More information about the use-livecode mailing list