AltME groups: search

Ah, good idea...a virtual printer in REBOL! That would make a nice 
framework if you can expose a simple API.

the api of the server might also tell you to put some values in the 
URL to specify the function you are accessing on the server, some 
prefer that in the post data, its all very site specific.

yeah.. i don't think i have enough info i the api

I can try with SOAP api provided, but i get the feeling it's going 
to be just as much of a time sink.

for example, I did an interface for the meetup.com site in an hour, 
but their API docs are VERY well done and its really simple.

is there a listing of changed natives?  I rarely find that they make 
things better, if they change the api of a function.

Almost all of the changes have been for the better, though some were 
mostly for greater consistency. Changing the API is OK if the old 
one was really bad, and if there is a rationale for having any change 
be OK. For instance, changes are much more restricted in new R2 releases 
since the continuing existence and development of R2 is the justification 
for allowing the more radical changes in R3.

I won't be able to grab the PID without some Windows API I guess

would it be possible to have more operators? In !Mikrotik group, 
I am trying do some stuff for MT routerOS API. Thanks to Anton, I 
can now proceed. When "studying" Python code, I found segment like:

elif l < 0x4000:
     l |= 0x8000


1) they can directly compare 'l of integer type to binary value. 
But I might make wrong conclusion here. But 'l is really result of 
len('string here') operation. But - even if so, I don't miss such 
an automation, as I can always write if l = to-integer #{8000}


2) Second line is more interesting - I did not find precisely |=, 
but found e.g. /= ... and it translates like do some operation, and 
assign. In this regard, the only comparable operator of REBOL is 
++ or --, but in R2 this is just mezzanine, in R3 native. But if 
I am right, their code:

l |=0x8000

R3:
l: (to-binary l) or #{8000}


So, if I would assume 'l being of correct type already (binary here), 
would it be possible to have?:

l |= #{8000}


Hmm, that is not probably compatible with REBOL parser and REBOL's 
assigment operator, which is :

No direct API I know of Max, but I'd rather stay portable as well.

Ones that aren't as huge either, and that can be accessed through 
a C API.

Besides DocKimbel has already published API documentation for using 
Curecode through REBOL.

My experience is, that Carl works in his own world, and it is good, 
we communicate with him via some "API" :-) E.g. I had to mention 
article about the need to use better timers (not done yet) for something 
like 3 or 4 times. Then, when I found the right time and his mood 
to actually look into it, I think that he agreed that there is better 
solution than what we now have ...

http://www.codeproject.com/KB/system/timers_intro.aspx


we imo need multimedia timers, definitely. So "small" change can 
make big difference. We don't ned to look pre W2K imo. And it is 
crazy that MS has all this mess in their API. The good thing is, 
that timers are host layer, so community can advance it ...

The problem is that the R2 DLL interface sucked. One of the base 
requirements of the R3 plugin model wass that it be powerful enough 
that you cold write a generic wrapper dialect as a plugin, and then 
use that dialect to specify the API a DLL.

thanks. I just have a little problem understanding 1), but never 
mind. So plugins are superset, the ability to extend environment. 
And as they can contain REBOL code, C code, they can contain even 
Device in itself? Well, it will be better to wait for API docs probably, 
to see some real-life examples ....

R3 devices wrap OS API (or third-parties API), no direct hardware 
access, that's way too costly to achieve.

Posted by Doc - "Having the TCP/IP part open-sourced in R3 will be 
great. It will allow to use much faster OS hooks for file transfers, 
extend the port! API to bind only on selected interfaces, etc...I 
wonder if the main event loop will be there also, so we can replace 
the not-scalable Select( ) call by other faster ones or even integrate 
libevent. That would definitely make Cheyenne able to handle a much 
higher number of connections."

in my case, it breaks every single API I have.

Its working on my system  :-)


when A80 is out, depending on what he will have added to the API, 
I will try to port a simple OpenGL game to REBOL  :-)

Every single broad decisision in R3 has been an enabling one for 
REBOL at large (both platform and language).   


Unfortunately, some things still require the core to be improved 
a bit, but we are nearing a point where REBOL will be able to fly 
on its own wings.   Just look at my attempt to get OpenGL to work 
with R3... it took me  10 hours of work from downloading the extension-enabled 
R3 version, downloading MS compiler, scrubbing the net for OpenGL 
reference material, libs, examples... and integrating all of this. 
 I've never coded OpenGL directly before... 


now imagine 100 of us doing this... that is what I see in REBOL's 
future within 2 years.  You will have things like trolltech QT bindings 
appearing, REBOL libs for any precise API out there... finally REBOL 
will be able to evolve with the rest of the world, and hopefully, 
impact its philosophy on the Computer Science more obviously...

Well, I probably think about them way too much as about objects. 
OTOH - I might have some module, but I want to hide my internals 
... kind of DLL aproach - you only provide docs with the accessible 
API and the rest should be hidden and even maybe signed ...

I think that in the end, browser-plugin will be opensourced. It is 
just small dll wrapper around NS plugin api (for all browsers except 
the MS ;-). I just remember, that we requested the ability to have 
multiple instances in one page, proper installation/update mechanism, 
and mainly - security. I still can't imagine, how it can be done 
in R3. BrianH surely keep an eye on security aspects, e.g. I doubt 
plugin will allow REBOL extensions, which might not be liked by ppl 
like Max :-)

IIRC the whole windows API is either ASCII or UTF-16.

they could not have taken vista and fixed it.  there was nothing 
good to salvage ... expect for aero, which is simply the api running 
over directx.

i'm sure  inwindows 7 the fixed fonts that turns to unfixedfont by 
magic is due to some unsuported instruction from win32 API emulator 
in winFX

cause rebol actually doesn't speaks the native vista/seven windowing 
API language it speaks the deprecated win32 API ...

I would like Cyphre to devote 5-10 days to core engine. E.g. transparent 
windows (not absolutly necessary for initial release, just an example) 
is just question of setting particular bit for API call, at least 
under Windows. I would like to see - Unicode, better fonts, cached 
gfx (we don't use bitmap caching yet), eventually switch to AGG compound 
rasterizer, some draw suggestions being implemented - so much for 
a low level ...

My favorites are:

- better font support
- ability to precisely measure font-size
- draw level events?
- move to Multimedia Timers
- transparent windows - just setting bits in API
- we don't use bitmap caching yet
- eventual switch to compound rasterizer

Actually - ppl still think, that before the host code is released 
(and hence host using Extension api (I think)), we are still dependant 
on you doing all the work ....

What is the Device model though? We have not seen any examples yet. 
So you take extension API, create some SQLite.dll (extension), and 
integrate it via Devices API?

What's missing is a REBOL storage mechanism like RIF which would 
enable developers to layer an access API (such as SQL) on top.

but the end goal is that we have ONE api for just about any kind 
of REBOL interface.

AFAIK, that will all be revealed within the host code shake down 
 :-)


devices are defined in the host and will be extensible, eventually. 
 they all use the same low-level/high-level api using fully async 
handlers.

You can choose to import just that list, or none, or go by a module 
reference, or import whatever visible words you want

 - eh, really? I thought that one of the ideas of the module is to 
 prevent user to mess with things. There are two point of views:


1) you debug some code, and your imported module function does some 
weird thing, so you want to debug foreign module. You can export 
some intermediate values from module (well, I am not sure it is best 
debugging method, but it is nice that such possibility is here


2) OTOH - you are a module author. Let's say you have some reason 
to protect your code/knowledge. So what you want is - compressed 
and scrambled source, checksum of code section into header field, 
and precisely defined Exports block of exported stuff = API to your 
module. And please don't push me to use Extensions in such a case. 
I am wondering, if security framework can be expanded, so that you 
can protect module/object, so that its words are not visible or gettable 
in any other reflective way :-)


I of course encourage to use open-sourced modules, but sometimes 
hidding the source and having only API exposed might mean a simplicity 
(user does not always need to look into internal, having headaches 
from thousands of line of code)

We can't, it has to be coded by Carl or someone with the source because 
of the API calls.

I am with ones proposing having read/write as simple as possible, 
adding just /as for codec support. Codec API should be defined, the 
same way as we have Device API, port API, etc. /string should be 
no excuse .... in the past (1.2 days), Holger posted to IOS:

read http://something.com:my-callback

Robert, how can Cheyenne know that "quantity" must be an integer! 
value if you don't tell it? Cheyenne can't validate that implicitly, 
you have to either use VALIDATE (see API doc) or make your own checking 
routines. By default, all your GET or POST  parameters are treated 
as string! value. If you need to check for their presence or need 
to convert them to another datatype, you have to validate the format 
so that it doesn't error out (or worth, let an hostile request pass).

SVN revision 12: Response/redirect default code changed to 302 (issuing 
a 303 could cause unwanted effect on HEAD requests). /TEMP option 
replaced by /STRICT for sending back code 303. RSP API documentation 
updated accordingly.

I've noted in my todo list to extend the RSP API to be able to add/delete 
jobs (for now, the list is static, loaded from config file and cannot 
be accessed from RSP).

SVN r18: 

DOC: added quick syntax overview for email API in %www/email.rsp

ooops ...

19/9-23:06:04.537-## Error in [OS-API] : OpenSCManager failed : Access 
is denied. !
19/9-23:06:04.539-[boot] Cmdline args : -vvv
19/9-23:06:04.540-[boot] Processed    : [verbosity 4]
19/9-23:06:04.541-[boot] Boot flags   : [no-screen verbose]
19/9-23:06:04.542-[boot] Data folder  : %./
19/9-23:06:04.545-[uniserve] Async Protocol FastCGI loaded
19/9-23:06:04.546-[uniserve] Async Protocol SMTP loaded
19/9-23:06:04.577-## Error in [dig] : DNS server not found !

UniServe API documentation : http://www.softinnov.org/rebol/uni-guide.html

HTTP async client implementation : http://www.softinnov.org/tmp/HTTP-client.zip

From what I've understood of your need, you should look into the 
"Protocol API" part (and not the "Service API" part).

This PHP code works fine..

<?php
 
 $password = "ClueCon";
 $port = "8021";
 $host = "127.0.0.1";
 
 function event_socket_create($host, $port, $password) {
     $fp = fsockopen($host, $port, $errno, $errdesc) 
       or die("Connection to $host failed");
     socket_set_blocking($fp,false);
     
     if ($fp) {
         while (!feof($fp)) {
            $buffer = fgets($fp, 1024);
            usleep(100); //allow time for reponse
            if (trim($buffer) == "Content-Type: auth/request") {
               fputs($fp, "auth $password\n\n");
               break;
            }
         }
         return $fp;
     }
     else {
         return false;
     }           
 }
 
 
 function event_socket_request($fp, $cmd) {
    
     if ($fp) {    
         fputs($fp, $cmd."\n\n");    
         usleep(100); //allow time for reponse
         
         $response = "";
         $i = 0;
         $contentlength = 0;
         while (!feof($fp)) {
            $buffer = fgets($fp, 4096);
            if ($contentlength > 0) {
               $response .= $buffer."<br>";
            }
            

            if ($contentlength == 0) { //if contentlenght is already don't process 
            again

                if (strlen(trim($buffer)) > 0) { //run only if buffer has content
                    $temparray = split(":", trim($buffer));
                    if ($temparray[0] == "Content-Length") {
                       $contentlength = trim($temparray[1]);
                    }
                }
            }
            
            usleep(100); //allow time for reponse
            

            //optional because of script timeout //don't let while loop become 
            endless
            if ($i > 10000) { break; } 
            
            if ($contentlength > 0) { //is contentlength set
                //stop reading if all content has been read.
                if (strlen($response) >= $contentlength) {  
                   break;
                }
            }
            $i++;
         }
         
         return $response;
     }
     else {
       echo "no handle";
     }
 }
 
 $fp = event_socket_create($host, $port, $password);
 $cmd = "api show dialplan";
 $response = event_socket_request($fp, $cmd);
 echo $response; 
 fclose($fp);

Here's the W3C Web Sockets API if you're feeling so inclined. 
http://dev.w3.org/html5/websockets/#the-websocket-interface

WS.rsp  should look like this

<%

;-- RSP API web sockets specific changes --
;

;   request/web-socket? => true if this is an incoming socket message, 
false if it's HTTP.
;   request/content/data => contains the socket message (string!)

;-- just echo back the message
//prin request/content/data

inc: request/content/data
if inc = "makedrag" [prin "$('#test').draggable();"]  

if inc = "Hello World" [prin "alert('Hello back');"]
 
%>

the connection is open, but RSP is stateless

 If you want to make it stateful, just store the data in session, 
 file, database, whatever...Most of RSP API is still working with 
 web sockets (response object methods will have no effect).

SVN r50

FEAT: /on-done callback support added to 'do-task function in socket 
application.

FIX: socket application API now has more homogeneous argument passing 
(client port always first now).

I guess it will be more clear once I make a few demo apps and write 
a doc for the new API.

Yeah, web chats....  avatars, skins, website integration, API integration 
with gmail, animations, sound, video and other media integration... 
those things really suck

SVN r59 : experimental mod-upload released.  This new mod adds server-side 
API for querying realtime progress info on uploaded files. See the 
demo : http://localhost/upload.html(not commented yet).

Current restrictions:
- works only when posting one file at a time in a given <form>.

- can't make it work for IE (IE seems to have an issue with setTimeout( 
) method).

SVN r61

FEAT: added request/store function to help manage uploaded files 
(see %changelog.txt).
FIX: IE issue with upload.html (cache issue). Works ok in IE now.
DOC: upload API documented in %www/upload.html.

Another handy html 5 api..  Web pages can determine if the client 
is online. (returns boolean)

var online = navigator.onLine;
alert(online);

Jison: An API for creating parsers in JavaScript
http://tinyurl.com/yeravlz

In addition to Henrik's answers, database access can be used in two 
ways, either "manually", opening and closing connection yourself 
from a CGI or RSP script (READ mysql:// prefered in that case), or 
by relying on the RSP webapp API to manage persistent connections 
(see DO-SQL function in RSP API doc).


In both cases, you need to load mysql-protocol.r. The best place 
for that is in the config file in GLOBALS section, just add :

worker-libs [
    %<path-to-mysql-file>/mysql-protocol.r
]


Usually, I define a %libs/ sub-folder in Cheyenne's folder and store 
there all the libraries used by all my RSP or CGI scripts.

Well, that's a good idea, but the SDK license is quite restrictive, 
I shouldn't distribute Cheyenne in binary form (see "REBOL API Restriction" 
part at http://www.rebol.com/docs/sdk/sdkintro.html). RT didn't asked 
me to pay any additional license so far, so I don't want to push 
it further by giving away a free /Command with Cheyenne.

fyi html5 has a new file api.. 
http://dailyjs.com/2009/11/30/html5-file-api/

Since the File API is asynchronous, files could be loaded and processed 
in the background while the user does other things. This could also 
be useful for creating web applications that work offline.

File Api Demo (requires firefox)
http://html5demos.com/file-api

Found this in misc/service.r


; TBD: replace alert function by a call to MessageBox win32 API (would 
work with both Core&View)
alert: func [msg /local svs][
	svs: system/view/screen-face
	svs/pane: reduce [
		make face [
			offset: (system/view/screen-face/size - 200x50) / 2
			size: 400x100
			pane: make face [
				size: 380x80
				offset: 0x24
				text: msg
			]
		]
	]
	show svs
	open-events
	wait []
	clear svs/pane
	show svs
]

This is what the SDK license says (so related to any encapping kernel): 
[...]

REBOL API Restriction. If you choose to export the REBOL API (function 
and objects of REBOL) for users of programs created by REBOL/SDK 
(in other words, you allow users of your programs to write and execute 
REBOL scripts within your program), you must obtain a separate commercial 
distribution license from REBOL Technologies. If your program does 
not allow users to access the REBOL API, then no additional license 
is required.
[...]
http://www.rebol.com/docs/sdk/sdkintro.html

So, finally... it's time that I learn how to use the RSP API.

SVN r96 -> r103 (most of new features were suggested by Carl)  


FEAT: encapped Cheyenne binaries now returns 0 (or, in case of panic, 
a REBOL error code) on exit

FEAT: (UNIX) Added a new command line option: -V or --version. Displays 
Cheyenne's version, then quits.

FEAT: (Windows) Cheyenne's version is now displayed in the tray icon 
help message.

FEAT: RSP debug mode extended to display tail of trace.log file using 
a new [show trace] button.

FEAT: RSP debug bar look improved, menu horizontal alignment fixed, 
direct link to RSP API online
documentation added.

FEAT: RSP errors are now displayed in an overlay popup instead of 
being inlined in the page.

FEAT: RSP debug bar javascript code footprint reduced to a single 
object: rspdbg (avoids polluting global namespace)

FEAT: new RSP API function: debug. Switches the debug mode on or 
off, for the current RSP script.

FEAT: new API function: debug?. Returns TRUE if debug mode is active.

FEAT: 'debug config keyword definition extended to accept an optional 
block of parameters.

FEAT: RSP session/start now returns the session/active? flag as result.

FEAT: (UNIX) Added a new boot option: -h or --help. Displays the 
command line syntax help and quits.

FEAT: Improved RSP function 'validate to accept default values for 
optional parameters when using
the /full refinement.

FEAT: now plain REBOL scripts can also be run by the RSP engine! 
(see www/show.r)

FEAT: new RSP API function: emit. Does a REDUCE on its argument before 
APPENDing to response/buffer.

FEAT: added new RSP syntax for emit-action : <%? ... %>. Does the 
same as 'emit, but inlined in a
template page.

FIX: (Windows) improved child processes termination with a more graceful 
method using JobObject API

FIX: (UNIX) optimized child processes termination using a kill() 
routine! wrapper instead of CALLing the shell command
FIX: flush HTTP logs in cache on exiting.

FIX: mod-userdir was still commented in config file modules list, 
disabling user/group keywords in httpd.cfg

More info on the new RSP functions in changelog.txt file.

I am using the example from the RSP API  - locale/set-lang 'fr

can anyone get a login for the cheyenne wiki?


I'd really like to put down my trials and errors of building my own 
cheyenne mod (with handler), so that others may benefit of knowing 
the few little caveats which can make the whole thing fail .... 
maybe do something like a step by step tutorial to begin with.


I'd also like to document all the phases of each internal layer of 
cheyenne (there are many), so that we can more easily navigate the 
code, knowing what we are doing and what other phase is part of each 
type of mod,extension, service, etc.   often, we see just one or 
two parts of a system implemented per module and its hard to get 
the whole picture.   


ironically, looking at the base objects is also hard to do, since 
there is so much "internal" code that it gets REALLY hard to understand 
what is internal, what is "interface" and what is provided as helper 
funcs for your own systems to use.  Add the fact that there are many 
layers sitting over each other, some layers which aren't actually 
layers of code, but layers in the "chain of command" and various 
phases.


now that I've made sense of a *portion* of this, I think I'm well 
placed to start documenting this.   I think that having a complete 
api reference for cheyenne would be really good for adoptance.


It would allow many of us to simply create integrated tools which 
just drop into cheyenne.  (like remark)

web api

ok, so I promised a little announcement about work I have been doing 
in/with/for cheyenne...

I have built a web service module (mod) for cheyenne.
  -----------------------
  features/highlights
  -----------------------

   * extremely fine tuned to cause the least cpu hit on the server process 
   since ALL processing is done in worker processes.

   * it uses an arbitrary number of rebol script files which you assign 
   to any host in the config file. (even the default)

   * once assigned, these files are compiled dynamically (as one app) 
   by the mod and are exposed via http by the server.

   * only the functions you *chose* are *ever* visible on the web, allowing 
   you to include support libs, data and function right in your server-side 
   api.

   * no direct execution of code occurs, *ever* from the client to the 
   server, all input is marshaled, and parameters are typed to your 
   function specs.

   * allows ANY type of web api to be delivered, from REST to SOAP like 
   interfaces.

   * output is programmable, so that you can output AS  json, xml, html, 
   txt, etc.

   * interface is also programmable, so that you can provide GET params, 
   POST forms, POST (XML, JSON, REBOL native data)

   * Automatic API documentation via source scanning and function help 
   strings .  there will also be some form of comments which will be 
   used by documentation.

   * No suport for sessions. this is part of your application layer, 
   which should use https and session keys in the submitted data, if 
   you require it.

   * it takes litterally 5 minutes to convert your internal rebol code 
   into web services which obey internet standards.

   * System is auto-reconfiguring... i.e.  you don't need to close cheyenne 
   to update the service, just restart the workers.

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

I recently implemented a soap api to interface with an online accounting 
package

yeah, but you still have to put the code behind.   the web-api mod, 
provides an interface automatically based on what is actually being 
served.  you could easily build a little WSDL to REBOL api file converter. 
 just load the XML, extract the methods, the parameters and build 
an equivalent rebol function stub.


Then all you'd have to do is implement the function body....  the 
only detail is the xml datatype which don't all map 1:1 within rebol, 
but that can usually be pretty well cornered within the code itself.

wrt api server speed  adding up all the required cheyenne server 
handling and tcp xfer we get:


>> s: chrono-time    read http://localhost:81/echo.xml?value=tadam 
     difference chrono-time s
connecting to: localhost
== 0:00:00.010442948

for those who might be using dividers and don't look at all the groups, 
I posted the release of mod-web-api in the announce group, yesterday.

s it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

 Yes, .r scripts are processed as plain REBOL scripts but with the 
 addition of the whole RSP API since r100 (http://code.google.com/p/cheyenne-server/source/detail?r=100).


It has been officialy documented on the wiki only recently: http://cheyenne-server.org/wiki/Rsp/Basis
("No-template scripts" section).

I was though ... and then using the Api reimporting it

Streaming: Cheyenne is sending big files in chunks of 1KB up to ~64KB, 
depending on the connection. It can serve multiple big files, but 
the scalability might be limited by the blocking disk read accesses 
delays. Other C-based servers can use OS API for async disk read 
accesses that we can't integrate into REBOL native ports.

as I say, it's not a practical problem for me. :) Just a suggestion.. 
I am making external API and I got some developers that are very 
sensitive to propper HTTP so I am rewriting my api to all those codes.. 
But this is not a problem for that, since API doesn't use cheyenne's 
sessions.. just while I am rewriting my ajax code I thought of it.

I will have a lot more experiences about this in few months because 
I am just working on this stuff regarding the API and export. I used 
aditional get param so user can select what format she wants. But 
I was educated by this guy that I should look at Accept headers, 
which I ignored happily ..:) .. same about statuses which I didn't 
use. Now I am getting home at this, so we can talk in a while and 
determine the most systematic and clean way for this. And such that 
will make the REST purists happy

INCLUDE is just the user API front-end.

No, it's the embed API, see 'publish-site and 'testapp specs in %embed-demo.r

As the (long) note explains it, it's a special API for closely integrating 
Cheyenne HTTP server with an existing app.

Chris' Google Chart API Dialect may be what you are looking for. 
 http://www.rebol.org/view-script.r?script=charts-api.r

when Carl adds a few little image! enhancements to the extension 
API, I should be able to use a rebol image! as the interface to get 
the OpenGL render into rebol, using R3 view.  If memcopy works, then 
it should be VERY fast ( a few hundred images/second AFAICT)

I need to wait for callback and/or image! specific enhancements to 
API to make it REBOL controlable

Open GL gfx source is mostly  on the C side for now because I'm still 
playing around with the extension and I can't interact with GLut 
or OGL until the extension API is expanded a little bit.

At this point, providing the full capabilities of OpenGL to REBOL 
seems trivial, once the image! improvements are added to Extensions 
API.


Some form of callbacks would also allow us to use a different window 
manager than VID (which would make it faster, since we wouldn't need 
to convert to rebol bitmaps at each frame).

I don't like point 2) - I think that Carl knows best, how to add 
integration of Devices, eventual callbacks, images, etc. - simply 
the requested stuff. We (the community) should use extensions, we 
should not try to develop its API.

Some explanation:


Back to OS X, the problem is that they're not really libs, they're 
.a's. This ev
en appears to be the case when -dynamic-lib is used.

I 
should mention that I've had -dynamic-lib built OS X libr3 and host 
working fo
r several days. But, the libr3 isn't in the form I want, 
because it's not intern
ally linked and resolved. Examining it with 
nm it looks like just a concat of .o
 files.

Specifically, I want 
all internal symbols resolved, and I only want to export th
e library 
interface.

If OS X only builds libs (dynamic or otherwise) as concatenated 
.o files, that's
 a serious breach of coding ethics! There are two 
reasons:

1. it means I can link against the internal interfaces 
- a serious short circuit
 in code encapsulation rules.

2. it means 
I can discover the entire internal structure of any product... say 
I
 want to peek inside Photoshop to see how it does something.

If 
I nm a lib that's been properly prepared, I should only see its API, 
nothing
else. So far, this has not been possible on OS X.

I suppose 
I could easily confirm this by nm'ing some of the various apps I 
have
on OS X and checking if I can see their internals. Let's hope 
not.

I'd like to pay someone to help me write a videoconference application 
in R2.  I've got a little VOIP script already working at http://www.rebol.org/view-script.r?script=intercom.r
.  Using the Windows MCI API that I knew, that simply writes a wav 
file to a file, and then transfers it.  I need a Windows/REBOL guru 
to help me continuously retrieve wave data in memory, to avoid gaps 
and delays in the sound.  Same thing with video.  My webcam script 
can only write images to a file - I need to have some Windows API 
code written to do it all in memory, without the delays associated 
with writing to a file.

Amount:  Please suggest an estimated amount

Offered by:
	TomBon
Task:

 R3 - Bindings for libcurl - the multiprotocol file transfer library
	http://curl.haxx.se/libcurl/

	C - API  -> http://curl.haxx.se/libcurl/c/allfuncs.html


  libcurl is a free and easy-to-use client-side URL transfer library, 

 supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, 

 LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET 

 and TFTP. libcurl supports SSL certificates, HTTP POST, HTTP PUT, 

 FTP uploading, HTTP form based upload, proxies, cookies, user+password 

 authentication (Basic, Digest, NTLM, Negotiate, Kerberos), file transfer 
	resume, http proxy tunneling and more!


 libcurl is highly portable, it builds and works identically on numerous 
 platforms, 

 including Solaris, NetBSD, FreeBSD, OpenBSD, Darwin, HPUX, IRIX, 
 AIX, Tru64, Linux, 

 UnixWare, HURD, Windows, Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, 
 OpenVMS, RISC OS, 
	Novell NetWare, DOS and more... 

Amount:
	$150
Valid until:
	01.11.2010
Terms:
	PayPal

offered by:
	TomBon
Task:
	R3 - Bindings for zeromq - concurrency framework
	http://www.zeromq.org/

	C - API  -> http://www.zeromq.org/intro:read-the-manual

Amount:
	$250
Valid until:
	01.03.2011
Terms:
	PayPal

offered by:
	TomBon
Task:
	R3 - Bindings for FANN - Fast Artificial Neural Network Library
	http://leenissen.dk/fann/wp/

	API  -> http://leenissen.dk/fann/html/files/fann-h.html

Amount:
	$350
Valid until:
	01.04.2011
Terms:
	PayPal

offered by:
	TomBon
Task:
	R3 - Bindings for GAUL - The Genetic Algorithm Utility Library
	http://gaul.sourceforge.net/

	API  -> http://gaul.sourceforge.net/documentation.html

Amount:
	$350
Valid until:
	01.04.2011
Terms:
	PayPal

offered by:
	TomBon
Task:

 R3 - Bindings for a KNNL - SOM (Self-organizing map) /Kohonen Network
	http://knnl.sourceforge.net/

	API - http://knnl.sourceforge.net/html/index.html

	Further Readings:
	http://en.wikipedia.org/wiki/Self-organizing_map
	http://www.ifs.tuwien.ac.at/dm/somtoolbox/
	http://accu.org/index.php/journals/1378
	http://www.codeproject.com/KB/graphics/som.aspx

	Alternativ:
	Quick Tutorial on how to construct a SOM.
	Perhaps to create a modul directly in R3?
	http://www.ai-junkie.com/ann/som/som1.html


Amount:
	$350
Valid until:
	01.04.2011
Terms:
	PayPal

*** Bounty Increment ***

Offered by:
	Gregg Irwin
Task:
	R3 - Bindings for zeromq - concurrency framework
	http://www.zeromq.org/

	C - API  -> http://www.zeromq.org/intro:read-the-manual

Amount:
	$150 (increment added to TomBon's $250 bounty)
Terms:
	PayPal

Of course what I really like about it is that there is a REST based 
API that I can use with REBOL.

Well I was reading their API again over the weekend on the plane 
:)

I haven't looked at the other services for a while now, and don't 
think I ever looked at the SOAP api for S3, and SQS .. but I suspect 
it's very similar, and just point the URL to a different service

Would you mind to show the interface/api or the actual implementation 
of your time scheme? You're probably (mis-)using the /LINES refinement 
of READ, but maybe you can instead use WRITE for that ...

I think R3 is too slow to benefit of such non blocking API.