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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
