[REBOL] Re: REBOL, Flash and Browsers and plugins
From: petr::krenzelok::trz::cz at: 11-Mar-2003 13:27
>[was Re: earth demo]
>>Ah, don't you think the better part of most Flash intros is the "skip
>> intro" button?
>Flash is a much richer language/environment than you'd ever imagine if you've
>just seen it being used to generate annoying demos. It's a fully-featured
>programming language that is one of the main contenders for future
>application delivery -- that's any form of application, not just annoying
exactly. We will either accept excuses and get nowhere, or take facts
for granted. What if I tell you that I wold like to see World demo
rotating 5 times faster? Well, that is not reply to you, Sunanda, but
just an extension to your comment regarding flash ...
>> What really bugs me is that REBOL does not integrate into browsers,
>Given that, increasingly, the browser *is* the platform these days, not
>integrating into a browser is a serious limiting factor into REBOL's reach.
>I seem to remember that there was an IE-only REBOL plug-in at one point. So
>it is possible; it just hasn't been carried through all the way.
Well, I think that having rebol drawing inside browser's window would be
nice, but otoh it is not imo necessity. It would be maybe sufficient
enough to have somehow .r (or other extension) registered, which would
tell browser to start Rebol and pass script to it. Following steps would
be imo needed:
1) Sorting out Rebol + registry issues. I would like to recommend to
discard any signle touch of Rebol products with registry. While I lost
my argument agains RT in the past, that it may be usefull to have such
registry association at least for typical user, I still think the
situation is rather messy and only causing problems. If Rebol does not
use one-exe + components strategy, then what product should be .r
registered to? View/Command? View? IOS? Core? - what if I want to have
it simply associated with my favourite text editor? I think that sorting
out this issue would add simplicity to rebol usage. Rebol's --noinstall
command-line option should be turned upon --install, and the logic
should be reversed ...
That is first - freeing .r extension ...
2) other pov could be to agree upon some other rebol extension ... we've
seen some of them already -
- rip - rebol archive
- rxx - new package distribution format? Extension name I don't remember
- rap - IOS closed source modules
I think that we are a bit leaving simplicity here once again - just tell
me, honestly, if you can easily remember how to create one of them, how
to unpack them, etc.? Some time ago I suggested to go for zip:// scheme
- some apps use it as storage mechanism (e.g. WinAmp for skins) and it
is readable by many tools and can be even secured by password (although
maybe not securely enough). Many file managers treat such known archives
as ordinary directory, so deployment is rather easy. Well, now let me
say that it is not fault of RT here. Carl asked for assistance here, but
we don't have skilled C coders probably to proceed in that direction
(OTOH without knowledge of rebol internals it could be a bit difficult
to implement in acceptable way)
So - another possible extension - rpl? Rebol player ... I will try to
First let me state that I don't know, what is general procedure to
register plug-in with browser. I only remember browser taking me to
certain download page, then dialog appeared asking me if I want to trust
Macromedia Stuff in future. So - is there any certificate checking, is
there any browser interface, thru which you have to regiter your plug-in
and its extension?
REBOL player could be kind of Encapped app. I installed Java and its
WebStart. Hey, they stoled View desktop idea, even in more primitive
way! View desktop is half-way there. "GO" button let's us to visit
various rebsites. The idea of REBOL Player could be mixture of two
a) Installation process of Rebol Player - mostly putting
rebol-player.exe into some dedicated directory. Apps would be installed
into subdirectories (in a similar way View Desktop does it nowadays) and
maybe going away from sandbox should be forbidded at all?
b) .rpl extension would be "somehow?" registered, so that browser would
know about REBOL Player and would pass url to it ...
c) rebol player would launch the app or it would add it to interactive
list of available apps, marking it as selected, and there would be
or "go" or "run" button ...
d) Rebol player would have auto-update feature as Cerebrus does. The bad
thing is, that with SDK, XORed executable is now bigger, as protocols
etc are part of your source, not executable anymore. Maybe it would be
better to use View + Encap in that regard
e) some data format for packed script - .rpl ... or we may use .rip or?
.... Central module (function) to check for newer version and if
auto-download-new-version checked, download it ...
Of course there are other questions I am not skilled enough to answer -
what would be the initial process? User writes
http://www.somedomain.com/someapp.rpl and how does browser know he/she
needs rebol player, where to find one, etc.?
Anyway - just a food for thought ... sorry for being so long, but I am
always trying to see things in wider perspective and cover all possible
overlapping issues ... maybe we can come app with some proposal and make
something usefull of it?
Looking forward to further discussion ...