Comments on: In focus: codecs as loaders and savers
As you will learn later this week, I've changed the R3 schedule to focus on a few layers below the GUI.
With Modules now available for testing, I want to get some of the main image loaders back into R3.
Of course, it's not a matter of just throwing them into the soup like we did on R2. In R3, image loaders are just a thin layer on top of decoders and encoders, codecs.
The soon to be released decode and encode functions are mezzanines that scan part of the system object for matching codecs, then evaluate accordingly.
It's not fancy, but it is useful. It's also more than just the primary R2 image loaders/savers; you will be able to provide your own plugins for any other formats you need. Got TIFF?
I decided that it was worth implementing the codec plugin concept first, as a step toward the more powerful R3 plugin components. We can work out some of the related issues easier this way.
Also, the bigger part of the task is to port the R2 resident decoders over to R3. In addition, I'd like to add-in UTF-16 and UTF-32 codecs, just so we have them done, and maybe some wave sound codecs, although I will admit we are seriously lacking any codebase for all variations of those (MIT, BSD, or any free/non-GPL implementations.) If you have ideas, post them.
This topic is very difficult for me, because I would like us to get it correctly done, while otoh I am not able to think of every possible consequence. My general requirements are:
- at least flexible system as Amiga datatypes
- I do remember related discussion in Prunning down read and write blog (http://www.rebol.net/r3blogs/0127.html). I refuse any read-jpg type of attempts. Instead I want system to be well abstracted, to allow: read/as %some-source :jpeg-codec param1 param2 - simply that read itself does not know anything about the source decoding.
- my previous point might be solved by encode/decode funcs. Could we know more about them? Are there just sync helper as is read/write on schemes? Remember - we want surely to support streamed encoding/decoding. The topic might be even deeper, because it might related to REBOL 'parse function (REBOL level decoders), and some of us requested parse to work upon streamed port stuff too ...
- could codec specs be abstracted via scheme as a general concept in REBOL?
As I said - I want things in R3 being done right, not rushed, and surely not accepting any "let's have rather this, than nothing" R2 aproach. But - I am not able to judge if I like the aproach or not, unless I can see one or two concrete examples - show me how single jpg loading/saving can be added - both C level and REBOL parse decoder level, and another example - streamed mp3 :-)
Pekr, thank you for the comments, and I agree that we want it done right. See the next blog for the first draft. Certainly, there is more to do, and there will be numerous special cases to consider and to be smart about how we add them.|
In fact, I've to admit that I want to expand a bit the concept in the future.
Why not write codec to load source code written in other language than Rebol. It could be great to load C, Java, PHP, Python sources. And why not natural language ?
Example in native language:
run world wide reb demo calculator
Another example form C source code
printf ("Hello World");
print "Hello World"
More interesting, we can use it to translate code into rebol.
There is a running prototype and it could translate some popular C/C++ libraries used in Linux source base. And the code works ! There are a lot of small problems to resolve (mainly date conversion issues), but there is a proof of concept.
Did you remember Wildman project ?
The question was "Can REBOL operate natively on specific hardware?". A way to reach this objective is to translate well written C/C++ kernel & drivers source code into Rebol.
Well, it has to be 1.April joke, no? :-) How do you want to translate C code into REBOL code?
Well, I don't understand those deep topics, so I better try to not excited. You know - we have got RebCode in R2, which due to design changes was taken away from us. IIRC guys thought about some plug-in (not codec) linked native "interpreter", which would allow us to get new RebCode or some partial compilers to native language. Some guys also thought about linking some small cross-platform C compiler with REBOL as a plug-in.
So - what is the relation (boundary) between codecs and plug-ins?
The third post was written by "Carl Sasssenrath" with 3 's', not by "Carl Sassenrath".
Yes this is a 1rst April joke !
Yes, I noticed it later too. Blog interface would probably allow to post even with regular Carl's name, but that person did not probably want to go so far. Anyway, my question of how to replace RebCode effectively still remains :-)|
Just a question: could the generic datatypes expose functions to manage the loaded data ?
sound: load mysample.mp3
Post a Comment:
You can post a comment here. Keep it on-topic.