AltME: R3 Extensions


Andreas, yes exactly these considerations are important because the sore temptation could lead into an overload and therefore polluted R3 with embedded extensions beyond a usefull 'R3 with batteries included' ;-)
there are tons of usefull libs and free code out there, compression, crypto, text processing, serialisation, image manipulation, audio, math, ai and very important;  db connectors. filling these areas step by step is a lot of work but I think it's worth. As soon R3 has reached a stable structure (couple of weeks I think) a new bounty system should be established for extensions we need but haven't the time or skills to create those. Just now I started with a simple one to get a feeling for the handling and any advise in this is highly appreciated.
Which library do you suggest for universal DB connection ?
Guiseppe, I'm going to add my ODBC extension, which is already available as dll. It's Windows only for now, but with the sources available, incorporation of Linux and Mac ports shouldn't be a problem.
There are several DB layer aggregators like OpenDBX, libDBI or even APR (as a function part). Problem here is most of them are looking outdated.
Afaict some of the ODBC APIs for Unix/Linux are kept up to date. Supporting those too would be a good idea. ODBC isn't Windows-specific.
Some NOSQL connectors would be fine too, not all supporting a straight REST interface. MongoDB, Redis and Tokyo/Kyoto offers a very clean C api.
Tomas, if you're working on Windows, you can write your extension in Red/System, using the dyn-lib-emitter branch of Red:
Kaj, thx for the info. now I am on the serverside (nix) to compare the handling and performance with the current Lua stack I am using.
Would be great if we could work on some extensions later, on the base we did before if you like ;-)
I'm open to it. R3 extensions in Red/System on Unix requires the dyn-lib-emitter branch to be finished and extended to other platforms
Alternatively, a Red(/System) host could be written that loads the R3 library, but that's not so simple, because there's no real separation in the R3 host code between the platform-specific and cross-platform parts of the host. That means you're almost forced to write the host in C, pulling in the existing C code
should Red/System not be advertised/pomoted a bit more as a better way to write rebol extensions, now that Rebol is OS? I mean, it should be listed on the Rebol GitHub project as the best way, if indeed it is. Possible on, if Carl would allow it.
possible = possibly
I think so, but only after the dyn-lib-emitter branch is finished
any ETA on that?
Ask Doc :-)
I should get back to it around early January.

Well, I am not good at those things, but having R3 extensions written in R/S seems a good oportunity to those, who are not much fluent in C, and always wished for more flexible R2 DLL interface, no? :-)

we have:
- COM Interface
- SQLite
- Licensing support functions
Great, will setup a page the next days, to list the current extensions with description/download link to get a better overview.
Just running the first embedded POSIX prototype here with a bunch of usefull functions like pid handling, fork, nanosleep, popen, execve, sig, pipe etc.

Last message posted 460 weeks ago.