AltME: R3 Extensions

Messages

TomBon
R3 extension will open the door to many usefull extensions now. We should collect the current status of existing extensions and of course
new ones we like to see.
Quick check on current extensions (lib based) :
cURL, ZMQ, ODBC, FMOD, IMagick...
Another area is what is the best practice to create and maintain embedded extensions, how to integrate a dynamic built for this how to organize the source tree.
Currently I am working on a embedded cgi extension as a testcase, this will lead also into questions like: mezz or native, embedded or lib?
Extensions on my list:
CGI, JSON, POSIX, PCRE and some math libs.
Andreas
Good initiative, Tomas. For CGI, I think you should get by purely with mezzanine code (environment, stdin, stdout).
GiuseppeC
Good initiative Sunanda
Andreas
(And I think technically, no native code would make CGI not really an extension, but a "delayed embedded module".)
Endo
"...we wouldn't need of 2 standard versions of Rebol (core and view)..."
That would be great, I remember that it was very confusing to me to have Core, Base, View, Face, Command etc.
Sunanda
Giuseppe -- thanks, but it was TomBon's idea in the SELF group.
TomBon
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.
GiuseppeC
Which library do you suggest for universal DB connection ?
ChristianE
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.
TomBon
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.
BrianH
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.
TomBon
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.
Pekr
Kaj
Tomas, if you're working on Windows, you can write your extension in Red/System, using the dyn-lib-emitter branch of Red:
TomBon
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 ;-)
Kaj
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
Kaj
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
AdrianS
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 rebol.com, if Carl would allow it.
possible = possibly

Last message posted 587 weeks ago.