[REBOL] Re: facts we will have to face ...
From: pwoodward:cncdsl at: 24-Oct-2001 10:35
Holger -
> On Wed, Oct 24, 2001 at 08:26:51AM +0200, Petr Krenzelok wrote:
> > Well, Rebol is nice collection of functionality. You can do many usefull
> > apps using Rebol, and I hope it will even become better. We can of
course
> > link to native libraries, but then we lose multiplatform advantage.
>
> Yes, but for Quicktime, RealAudio/Video and a lot of other standards
> that is the only solution, because these formats require codecs that
> implement the patented image/sound compression schemes.
What about using a "launch" feature similar to the "browse" function? On
the other hand - I'm pretty certain that using "browse" on a media type that
your browser (IE/NS/Moz, etc) understands will cause the appropriate player
to launch... In fact, after testing it with a one-liner, I know it does.
browse %01.avi
It doesn't even launch the browser window (or if it did, the browser window
closed so quickly I didn't see it). Pretty cool. Wow - multimedia
support
w/o even having to really extend REBOL.
> The best possible solution is to work within the APIs and dev kits
> that companies like Apple or RealMedia provide, and implement support
> in REBOL by accessing their libraries. Of course this means that not
> all platforms can be supported. We have looked into that, and
> it seems possible, but at the moment other things have higher
> priorities. Would be an interesting third-party project though:
> all you need is View/Pro, the dev kit and a lot of time :-).
Even this would be a PITA. I'm not sure, but somehow I doubt that
REBOL/View in any form has a great amount of compatibility with the
underlying OS and APIs. On Windows, the playback area of the media player
is a pretty special display viewport - trying to embed that into a
REBOL/View interface could be impossible w/o some serious changes to the
engine (just guessing here). While one could use a codec library to
decompress and hand back display information to REBOL - you'd then have to
have a REBOL native routine to translate those bytes into something the
/View engine could handle...
That's a lot of data shutlling in and out of the REBOL engine to the library
and back. Much like dealing with components in an ASP website, or thunking
native code from within Java - there is a performance penalty to marshal the
argument data that gets handed into the native code - and then handed back
to the caller. So you better be sure that what you're handing out to be
processed can be processed much quicker - quick enough to offset any
penalties from marshalling all that data.
- Porter
