• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!R3 Extensions]

Sunanda
18-Dec-2012
[1]
For discussion of Extensions:
    http://www.rebol.com/r3/docs/concepts/extensions.html
TomBon
18-Dec-2012
[2]
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
18-Dec-2012
[3]
Good initiative, Tomas. For CGI, I think you should get by purely 
with mezzanine code (environment, stdin, stdout).
GiuseppeC
18-Dec-2012
[4]
Good initiative Sunanda
Andreas
18-Dec-2012
[5x2]
(And I think technically, no native code would make CGI not really 
an extension, but a "delayed embedded module".)
(See http://www.rebol.net/r3blogs/0280.html)
Endo
18-Dec-2012
[7]
...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
18-Dec-2012
[8]
Giuseppe -- thanks, but it was TomBon's idea in the SELF group.
TomBon
18-Dec-2012
[9]
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
18-Dec-2012
[10]
Which library do you suggest for universal DB connection ?
ChristianE
18-Dec-2012
[11]
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
18-Dec-2012
[12]
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
18-Dec-2012
[13]
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
18-Dec-2012
[14]
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
18-Dec-2012
[15]
http://www.linuxnetworks.de/doc/index.php/OpenDBX
http://sqlapi.com/
http://sqlrelay.sourceforge.net/about.html
Kaj
18-Dec-2012
[16x2]
Tomas, if you're working on Windows, you can write your extension 
in Red/System, using the dyn-lib-emitter branch of Red:
http://red.esperconsultancy.nl/Red-REBOL-3
TomBon
18-Dec-2012
[18]
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
18-Dec-2012
[19x2]
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
AdrianS
18-Dec-2012
[21x2]
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
Kaj
18-Dec-2012
[23]
I think so, but only after the dyn-lib-emitter branch is finished
AdrianS
18-Dec-2012
[24]
any ETA on that?
Kaj
18-Dec-2012
[25]
Ask Doc :-)
DocKimbel
18-Dec-2012
[26]
I should get back to it around early January.
Pekr
19-Dec-2012
[27]
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? :-)
Robert
20-Dec-2012
[28]
we have:
- COM Interface
- BEEP
- SQLite
- Licensing support functions
TomBon
20-Dec-2012
[29]
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.
Bo
20-Dec-2012
[30]
Pekr, Yes!!
TomBon
22-Dec-2012
[31]
Robert, do you have a download link for your extensions mentioned 
above?
Robert
22-Dec-2012
[32]
Not yet. Still building it up.
GiuseppeC
22-Dec-2012
[33]
BEEP = Blocks Extensible Exchange Protocol ?
Robert
22-Dec-2012
[34:last]
Yes.