AltME groups: search

FYI, I am making good progress on the Red runtime, but I had to start 
implementing the Red compiler earlier than planned, to be able to 
define more accurately the right runtime API that the compiler needs. 
So at the time that the runtime will be ready, I should have a first 
Red compiler partial implementation working.

james - there is no Red yet, just Red/System. And yes, you can kind-of 
create Android apps. But - those are bare-bones linux ARM apps, which 
can run on an Android phone. I tried that on my HTC Sensation. Right 
now, there is no app-store support, nor the ability to link to Android 
API, which would require the JAVA bridge. You can find some info 
here - http://www.red-lang.org/2011/12/arm-support-released.html

GUI, nice would be a clean cross plattform ANSI C lib, handling the 
basic window & eventmanagement

and providing access via a simplified meta-api (VID-DSL). this way 
nearly all script languages could 
use this lib as a native GUI generator.

I don't think it is useful for Red/System, look at Kaj's bindings, 
its all system structures, API calls, enumerations and a few functions.

When we have Red we (or someone) can write wrappers in Red, so "normal" 
users will not need to use Red/System.

And there is no use series etc. kind of high level features in bindings/API/kernel 
calls.

But in short - Red is going to be compiled language, and it will 
probably get some kind of JIT too, to allow interactive stuff like 
console. Red language compiles down to Red/System, which is kind 
of VM for it. In fact, it is REBOL-like low level wrapper to C, allowing 
some bindings. Red/System apps recently run even on ARM, eg I am 
able to run it on my HTC Sensation. But that's raw ARM Linux, no 
Android API linking yet ....

@Gerard: 


Red will allow to extend itself in several ways. New types could 
be added easily by defining a set of new action! functions associated 
with a new datatype!. Also, the language syntax and semantics themselves 
could be changed by using the internal compiler API (not sure I will 
implement that in the bootstrapped version to avoid compatibility 
issues with the final compiler version).

In case, you wonder why Red needs both UTF formats, well, it's simple, 
 Windows and UNIX worlds use different encodings, so we need to support 
both. Red will use by default UTF-8 for string values, but on Windows 
platform, it will convert the string to UTF-16 on first call to an 
OS API, and will keep that encoding later on (and avoid the overhead 
of converting it each time). 


We might want to make the UTF-16 related code platform-depend and 
not include it for other platforms, but I think that some text processing 
algorithms might benefit from a fixed-size encoding, so for now, 
I'm for including both encoding for all targets.


It will be also possible for users to check and change the encoding 
of a Red string! value at runtime.

Ok, no metadata, I was wrong. See http://www.mega-nerd.com/libsndfile/api.html#read
sf_count_t is 64 bit integer.

some kind of brige is required, if we want to get into an Android 
API. Ditto for .NET?

Blender: yes, API is huge and it's a lot of work, but I'm convinced 
that Red, with appropriate dialects, would do wonders there and it 
could be a great way to make Red known.

There is a bit that is worth learning from R3's Unicode transition 
that would help Red.


First, make sure that strings are logically series of codepoints. 
Don't expose the internal structure of strings to code that uses 
them. Different underlying platforms do their Unicode APIs using 
different formats, so on different platforms you might need to implement 
strings differently. You don't want these differences affecting the 
Red code that uses these strings.


Don't have direct equivalence between binary! and string! - require 
conversion between them. No AS-STRING and AS-BINARY functions. Don't 
export the underlying binary data. If you do, the code that uses 
strings would come to depend on a particular underlying format, and 
would then break on platforms where the underlying format is different. 
Also, if you provide access to the underlying binary data to Red 
code, you have to assume that the format of that data can be corrupted 
at any moment, so you'll have to add a lot of verification code, 
and your compiler won't be able to get rid of it.


Work in codepoints, not characters. Unicode characters are complicated 
and can involve multiple codepoints, or not, but until you display 
it none of that matters.


R3 uses fixed-length encodings of strings internally in order to 
speed things up, but that can cause problems when running on underlying 
platforms that use variable-length encodings in their APIs, like 
Linux (UTF-8) and Windows/Java/.NET/OSX? (UTF-16). This makes sense 
for R3 because the underlying code is compiled, but the outer code 
is not, and there's no way to break that barrier. With Red the string 
API could be logical, with the optimizer making the distinction go 
away, so you might be able to get away with using variable-length 
encodings internally if that makes sense to you. Length and index 
would be slower, but there'd be less overhead when calling external 
API functions, so make the tradeoff that works best for you.

That's not as hard as it sounds. There are only 3 API models in wide 
use: UTF-16, UTF-8, and no Unicode support at all. A given port of 
Red would only have to support one of those on a given platform.

Red user code would only need to support the codepoint-series model; 
Red would translate that into the system's preferred underlying model. 
More encodings would need to be supported for conversion during I/O, 
of course, but not for API or internal use.

So far, my short-list of encodings to support are UTF-8 and UTF-16LE. 
UTF-32 might be needed at some point in the future, but for now, 
I'm not aware of any system that uses it?


The Unicode standard by itself is not the problem (having just one 
encoding would have helped, though). The issue lies in different 
OSes supporting different encodings, so it makes the choice for an 
internal x-platform encoding hard. It's a matter of Red internal 
trade-offs, so I need to study the possible internal resources usage 
for each one and decide which one is the more appropriate. So far, 
I was inclined to support both UTF-8 and UTF-16LE fully, but I'm 
not sure yet that's the best choice. To avoid surprizing users with 
inconsistent string operation performances, I thought to give users 
explicit control over string format, if they need such control (by 
default, Red would handle all automatically internally). For example, 
on Windows::

    s: "hello"		;-- UTF-8 literal string

    print s		;-- string converted to UCS2 for printing through win32 
    API
    write %file s	;-- string converted back to UTF-8

    set-modes s 'encoding 'UTF-16 ;-- user deciding on format
or
    s/encoding: 'UTF-16

    print length? s	;-- Length? then runs in O(1), no surprize.



Supporting ANSI as internal encoding seems useless, being able to 
just export/import it should suffice.

BTW, Brian, IIRC, OS X relies on UTF-8 internally not UTF-16.

I plan to use an abstraction API for memory management, so that we 
could in future, implement different ones.

Has anyone here worked with OAuth and/or the etzy.com API in REBOL? 
 I'm currently looking through Christopher Ross-Gill's OAuth implementation 
for Twitter, and interested in writing a REBOL app using the etzy.com 
API.  I understand most of it, but don't get the "oauth_signature" 
spec.  Don't have much time for this, so would like to offer some 
$$$ for anyone able to instruct and or provide help implementing 
the etsy API.  Email reverse "g r o  tod  z r a t i u g  ta  codmorf"

You just need to screen through %runtime/actions.reds and %runtime/natives.reds 
for changes. You could even make a short script to notify yourself 
when those files are modified using github's API. ;-)

We might even be able to implement the API that the storage engines 
plug into, which would allow us to use the storage engines unchanged.

Agreed. And it will be easier to keep an API clone updated for future 
SQLite changes, so we can get the benefits of future improvements 
to the storage engines.

Pekr: your remark about the stack made me think about it. I might 
change a bit the current internal API, collecting arguments from 
stack in trampoline functions (actions.reds) instead, and then calling 
datatypes-specific actions passing them the arguments directly. This 
would reduce the runtime code size a little bit and might simplify 
the construction of the future public API. I need to see first if 
they are drawbacks before deciding to refactor the code in that way.

Those functions don't have any arguments, they seem to work with 
the stack directly? Strange concept. Are those real Red functions?


They are Red actions (the datatype "methods" if you prefer). Polymorphism 
support is implemented through a dynamically created actions jump 
table. If you really want to see how this internal API works, just 
compile small Red test scripts with the -v 1 option (-v 2 will also 
give you the generated output of boot.red compilation).

In between, here is the PyOpenCL lib link for those interested to 
see how the OpenCL API is accessed by other languages - and this 
could pave the way for some Red binding ... http://mathema.tician.de/software/pyopencl

Also, for direct GPU access, it will only be doable for GPU that 
have all the required specification published (unless drivers provides 
the right API already).

It was a bit painful commit anyway, as the internal API is not yet 
fully stabilized and to do it right, I would need to fully define 
the public runtime API first, but that would delay the 0.3.0 way 
too much, so we'll deal with that later.


What I mean by "public runtime API", is the Red API exposed to Red/System 
and to other host languages loading Red as a library. I'm still uncertain 
if such public API can be just some internal exposed or will need 
a thin layer of wrappers to make it handier (and in some cases, safer) 
to use. 


The R3 extension isolation model is too strong for my taste and makes 
the extensions harder to write than they should. I'm also uncertain 
if this model was stricly motivated by providing the safest possible 
interface with the core or, if the willing to keep the core internals 
as secret as possible was also playing a big part in this model choice.


Once the `dyn-lib-emitter` branch merged, I plan to study the Lua 
(and others) public API, to see if and how we can do better for Red. 
I already have a rough idea of how it should look like, I just need 
to refine it.

Public API stability: right, that's a good point in favor of a set 
of wrappers on top of current Red runtime API.

A stack-oriented API might be a good candidate for that...

Anyway, we want to expose Red API to host languages/apps, not Red/System's 
one (at least not for now).

Part of the motivation of the R3 extension/host API was to isolate 
the extensions and hosts from changes in the underlying data model, 
which makes hosts and extensions really resilient to upgrades of 
R3. It also was designed to let you have a consistent internal execution 
model even in cases where the host has a completely different process/thread 
model.

They changed their API a few weeks back

AdrianS: we can make the lexer part of the upcoming public API accessible 
when compiling Red script as shared library. If you have suggestions 
about how the lexer should be exposed in order to facilitate integration 
with code editors, let me know.

WebKit has been changing their API a lot, so the binding is only 
for the older version. Segfaults and such would be expected when 
fooling it. Also, the GTK binding is developed for GTK 2 at the moment. 
I'll update them when I start running newer versions myself

NT: I don't see much the connection with console-oriented programs.


Windows 95 support: all current win32 API bindings Red uses might 
not be compatible but Red could easily be made to work on such platform 
though.

But they tend to crash R3 a lot when the command api fail

I have just uploaded a basic script to generate Red/System API docs 
to Github. It could do with a lot of polishing, perhaps you could 
take a look?

Red/System API Docs ... Just what I need, Thanks, Peter. :-)

Curious too about time frames for file access, network protocols, 
2D drawing API, sound, etc.  Are those things on the horizon yet? 
 Looking forward to when you can port higher level things like mysql 
dialect, games demos, etc.

Henrik, I agree. However, documentation that just regurgitates the 
api that can be gleaned with "help" word is next to useless - documentation 
needs to explain a lot more about a word than the api does - iat 
least: ts reason for existence, how to use it, and examples of usage.

Ok, I see what you mean. Like in C, you can already write "thread-safe" 
code in Red/System by using only variables on stack. If you need 
concurrent access to global variables, usually, the OS are already 
providing some API for that (locks, semaphores, mutex,...). I haven't 
chosen yet how it will be implemented at Red/System level, there 
are different options. For example, it could be handled by the language 
directly using a similar construct as in Java:

    synchronize [ x: x + 1 ]


In my early design notes, I have researched only how to handle concurrency 
at Red level, I've left the underlying Red/System part as an "implementation 
detail". I plan to start working on it after I/O will be implemented.

Another thing: are natives more efficient than routines?

  Routines and natives are both Red/System code that use Red runtime 
  internal API, so they perform the same. In case of routines, you 
  might have a tiny overhead for integer! and logic! that are converted 
  back and forth between Red and Red/System, but it is really very 
  small, and only significant if you iterate a lot of times over a 
  routine call.


From the memory and boot time perspective, natives are more efficient 
because their body block is not stored internally  for reflection 
like routines. So, for functions like QUIT that should be part of 
Red core, it is better to implement them as natives, to save memory 
and booting time.

Yeah, significant extra work to interface with it. But there's a 
shortcut, a API is also available through a builtin websocket server, 
so you can access the device from your browser directly.

(Add a 3D API, and maybe Red could find a market in gaming)

Kaj: interesting finding, but no that surprizing as the interfacing 
of Red with Windows API is currently quite limited.

I'm counting 27 datatypes implemented so far in Red. The next on 
the list will be: typeset!, errror!, object!, port!, binary!. Although, 
I'm not sure in which precise order they will be added (especially 
for error! and object!, not sure which one I'll do first).


For other datatypes, like float!, date! and time!, which are not 
a requirement for building Red core itself, I would like them to 
be contributed if possible. I could provide a sample empty datatype 
file and instructions on how to use Red's current internal API to 
anyone willing to work on them.

There are some things in R3, particularly some of the things that 
the module system can do, that probably won't make sense to do in 
Red because it's compiled. Delay-loading modules won't be as important 
for Red because most of the overhead of creating a module can be 
done ahead of time when it's compiled. It would make sense to support 
the delaying feature because you might want to have a module's side 
effects happen at a particular time, but the delay can happen a lot 
later in the process than it would in R3. Red might benefit from 
the options specification method and some other aspects of its surface 
API and behavioral model, but the implementation would be completely 
different. The restrictions we made to make the module system statically 
resolvable (in R3's case by a preprocessor like prebol or Ladislav's 
include) would be a lot more important for Red than they have been 
so far for R3, because compilation makes static resolution more important.

Of course, you'll need to use the internal Red runtime API and stack. 
No docs for now, as it is not stabilized fully, but you can guess 
a lot of it from other natives and actions implementation.

An internal API documentation would be a good start, but that API 
is not yet fully stabilized...

As several followers have requested some docs for the internal API, 
I will see this week, if I can find a few hours to write a basic 
one, just to get you started.

A first pass at accessing the Etsy API: http://reb4.me/r/etsy


Works similarly to my Twitter API script (a few OAuth differences 
here and there). You can download it, or run it in place (do/args 
... [...Settings...]). As with Twitter, you start with etsy/as and 
go through the authorization process.  It has a few example methods, 
and an open method - etsy/api-call - that can call (as far as I can 
tell) every api function. Will try to document at some point.

I wrote a tutorial that makes use of Chris Ross-Gill's Etsy.r module: 
 http://re-bol.com/etsy_api_tutorial.htmlThe focus of this one 
is all about helping the Etsy API developer team, but by necessity, 
it teaches all the REBOL basics, along with all the absolute beginner 
concepts.  I'm hoping the Etsy guys will write a blog post about 
it and help drive some more traffic toward REBOL :)

Released R3 ODBC host extension to https://github.com/gurzgri/r3.git
(branch odbc). 

It's a fairly complete, Windows only extension in the spirit of the 
R2 ODBC api.

It's pretty horrible what one has to do to hammer the chaotic C library 
API into a neat REBOL model

Yes, thanks. Have you looked into the opposite, having your program 
react to externally triggered suspend and hibernate events? Vista/7/2008 
has an api for that...

Ah, but that is exactly what the API is for. Programs are notified 
through the API that the system is about to shut down, whatever, 
and then those programs can save their running state and reload automatically 
after the restart and pick up where they left off. It happens for 
power failures too, if you have a UPS or laptop battery.

Note that my Etsy API script does patch HTTP (for purposes of retrieving 
API error messages).  You can view those changes here: http://reb4.me/r/etsy-http-hack.r

until something is tested in court (in your country) its dangerous 
to assume.    Goggle's recent java API court issues shows how you 
can get in trouble over things which even seem pretty clear.

Yes, JPEG can be compressed further. 85% JPEG is the 'standard' on 
the iPhone. Apple made some API, which gives 85% JPEG. The default 
camera app on the iPhone output 85% JPEG.

Sure. There are different milestones for a language integration. 
The first, to get the language hooked up to the API is probably not 
a huge effort. The second, to make existing projects work in the 
new language, is a different matter.

p.s.: any luck with the new mod-api release?

wrt mod-api... yes, and no, I was temporarily assigned to another 
project, but should get back to it tomorow, so I hope to have a release 
next week.

Thank you BrianH.

My question is, REBOL process (console or encapped app.) doesn't 
automatically detect of the time zone settings change of the PC.
>> now/zone
== 3:00

>> ;I changed my local time zone to +2 GMT or it changed automatically
>> now/zone
== 3:00


Is there a way to "refresh" zone in NOW, without closing and reopening 
the app.

Let's say I get the Windows time zone using a Win32 API. Then something 
like
>> now/zone: 2:00
== 2:00
>> now
== 8-May-2012/23:45:16+3:00 ;doesn't work

any luck with the new release of mod-web-api?

I also added path support for the mod so that you can use the same 
domain for web and api services.

there is no device code in the host-kit (which is the C api to rebol)

There was a plan to make device extensions, but Carl didn't know 
what API to use. He did a callout for advice, but that didn't get 
much response.

There has to be something Rebol is doing beyond a simple language 
api to get level of security purported by Carl. 
What kind of pipes does it use?

I remember CFOR, it was interesting. It's not FOR compatible though. 
What I was hoping to put in rebol-patches was a function with the 
same API as FOR, but without the bugs. Additional functions are great 
too, but out of scope for the rebol-patches project.

OK, cool. Will it have the same external API, so that if it is used 
in the same way (without obscure hacks) it will do the same thing? 
I'm OK with changing its behavior when you change the variable in 
mid loop, as long as that isn't commonly done in R2. If it's too 
incompatible that would be more something to put in R2/Forward (I'm 
spliting the fixes from the major changes).

Has anyone worked with the Amazon aws services?  I'm not sure how 
to "Calculate an RFC 2104-compliant HMAC with the SHA256 hash algorithm" 
as described in step 8 on page 62 here:  http://awsdocs.s3.amazonaws.com/Associates/latest/prod-adv-api-dg.pdf

Endo, ADO is a layer over ODBC. ODBC is closer to the db. People 
used ADO because it had an object-oriented API, useful for ActiveX 
languages. ODBC has a lower-level API that was more awkward for OO 
programs to use directly, so they used it through ADO.

Haven't tried OpenDBX yet. Don't know how R3-like its REBOL API is.

ChristianE implements an R2-like API in an R3 port model, and it 
just feels alien, though it does allow me to have more portable code 
between R2 and R3. This helps when i have to have a script extract 
data in R2 because it needs to get text or numeric type data, but 
then close and call itself in R3 to parse that data. My %rebol.r 
is R2 and R3 compatible.

I figured out a way to make an R3-like ODBC API, and have an R2-like 
API emulated when you try to use it in an R2-like way. But then I 
ran out of time, was assigned to other projects for a while.

Knowing C, it would be better to add it to the ODBC API, at least 
for someone who already knows SQL. That way you can get wider database 
support, since most SQL database vendors support ODBC. Heck, even 
Microsoft is making a free unixodbc driver for MSSQL.

I may find some time to tweak the R3 ODBC-API a bit if you could 
supply a prioritized list of things that need work. Regarding problems 
with certain SQL types one easy workaround could be to just allow 
all types without direct support by rebol to read them as strings, 
you then could do anything you like withthem. Regarding "R3's documentation 
for its port model is a bit lacking" - I surely won't have any time 
to find out why the port model I used feels alien to R3 without the 
better R3 beeing documented anywhere.

if you are looking for a fultext/searchengine don't miss elasticsearch. 
scales well, based on lucene, very fast, simple to use.

the interesting part is the compact rest api the storage model and 
the number of different analysers, tokenizer (snowball, ngram, etc). 

you can use elasticsearch also as a standalone nosql database with 
rebol. speaks completly json. 

working currently with 1.2 m documents + datastorage on a single 
machine.  runs very smooth. 

evaluated other components before (sphinx, xapian, tokyo etc.) elasticsearch 
has it all and is much cleaner to handle than solr.

http://www.salesforce.com/us/developer/docs/api_rest/Content/quickstart_oauth.htm

Is this the API you're trying to access?  Looks as if it uses OAuth 
2.0 (Etsy and Twitter are 1.0) - I'm not fully aware what the differences 
are.  Note that even though Twitter and Etsy both use the same signing 
method (OAuth), they differ in how you get the user key - looks as 
if this one is different again...

Hmm, that came across as unreadable here : ) - here it is again:


http://www.salesforce.com/us/developer/docs/api_rest/Content/quickstart_oauth.htm



Is this the API you're trying to access?  Looks as if it uses OAuth 
2.0 (Etsy and Twitter are 1.0) - I'm not fully aware what the differences 
are.  Note that even though Twitter and Etsy both use the same signing 
method (OAuth), they differ in how you get the user key - looks as 
if this one is different again...

sqlab, I didn't say invisible, just a lot less visible. You should 
realize that outdated documentation is essentially "noise" which 
makes learning what's current more difficult. Of course there should 
always be a way to get to an old API reference. On an authoritative 
source, this should be done in a very subtle way so as to minimize 
information overload - maybe with a clear, but small link at the 
bottom of the current version docs. Non-authoritative sources can, 
of course, maintain all the old information and present it in any 
way they choose.


When it comes to advice on best approaches, optimizations, etc., 
it's very important to promote the "current" recommended way of doing 
things so that new code being written based on these docs don't lead 
to the incorporation of work-arounds for problems that have long 
since been worked out.

Many wikis have an API

I'll try to get back later, to pull other doc links from the #Red 
group. In the meantime, here is one:

http://wiki.gigaspaces.com/wiki/display/XAP9/XAP+9.0+Documentation+Home


I like the upper right link categories: API docs, Forum, Blog, White 
Papers.

http://www.wikidot.com/doc:api-methods

I would like to copy this extjs template component for documentation, 
with content in JSON format:
- http://docs.sencha.com/ext-js/4-1/#!/guide
- http://docs.sencha.com/ext-js/4-1/#!/api

I guess it should be search-engines friendly.

I like the sencha guide page OK, but I like http://clojuredocs.org/quickref/ClojureCore 
better than the sencha API page. It seems like a better fit for Red/REBOL 
to me. Guess I'll really have to learn git now. 


Now, where is that new version of altme that uses git for file sharing 
and just hides all the details...

What I like about http://clojuredocs.org/quickref/ClojureCore, 
compared to the rebol dict page and senha API page, is:


- No need to expand or collapse the TOC on the left. You can see 
two top-level headings. 

- Single scrolling page you can scan. And I do like the visible scrolling 
in this case.

- Summary doc string visible for each item. Again, good for scanning.

- Having the number of examples listed is nice, and shows what needs 
examples.

- It's a clean, effective layout to my eye, providing useful detail 
before drilling down.

Gregg: documenting the API (the Red words) is the easy part. The 
content could (should?) be extracted from the docstrings in boot.red 
(I haven't add any so far, contributions are welcome).


The level of info displayed by the clojuredocs quickref is fine to 
me, I have used similar approach in the past for documenting the 
RSP API: 

http://cheyenne-server.org/docs/rsp-api.html

Agree that examples are a must have. I see way too many reference 
sites that just show an API along with a brief description. Even 
when these are very nicely presented, they leave me wanting. Seeing 
an APIs in action makes a huge difference to me, but of course the 
work of creating examples should come from the community.

Or just use syscalls .The posix extension I am working on will provide 
these features, template based creation too. 
for windows you can use this api call.  


http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991(v=vs.85).aspx

example:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363875(v=vs.85).aspx

Robert - do you mean IOS? I still think, that it was kind of superior, 
although it lacked cross-reblet API. Can you see all those Google 
drives, SkyDrives? Cross device, cross user file syncing could be 
done agas ago with IOS (/Services), if RT would have some product 
manager. Pity for lost oportunity. I still think, that something 
like IOS kernel/layer could or even should be used for OpenME ...

http://www.codeguru.com/cpp/misc/misc/cryptoapi/article.php/c8195/Portable-Cryptography-API-for-Triple-DES.htm

C and C++ implementations

Also, SO has an API so we can potentially grab all the Rebol tagged 
questions and also host them on rebol.org if we need to.  It's not 
stuck in the SO system

Windows has a gethostname API. I always liked the read dns:// feature 
though.

in a make/makefile for osx-intel:
TO_OS?= TO_OSXI
...
RFLAGS= -c -D$(TO_OS) -DREB_API  $(RAPI_FLAGS) $I
HFLAGS= -c -D$(TO_OS) -DREB_CORE $(HOST_FLAGS) $I

Not easy and flexible enough. You proved that we can do this already 
with the two-line implementation, but it doesn't have the syntactic 
sugar that the list comprehension fans need. So we might want to 
rethink the API but keep the power. Sometimes I think you're too 
smart for dialect design, Ladislav :)

I just updated it to fix a couple more bugs; haven't read any of 
Gregg's comments so I don't know what those strange behavior are, 
but they might be fixed now. I am more a fan of its API style - we 
can fix any internal problems.

MaxV: "This way you have to write very long commands to achieve the 
most simple tasks (show mybuttob/gob ... mybutton/gob/size). Is it 
just my impression?"


My guess is you are not using R3GUI correctly. If you are using the 
current included R3GUI styles you shouldn't be forced to write any 
SHOW commands at all(the SHOW command is considered 'internal' in 
R3GUI and shouldn't be used anyway). Just use the SET-FACE/GET-FACE 
api to make changes to the specific style.

In worst case (usually when some ON-GET/ON-SET handler is unfinished/incomplete 
in some style) you can either try to enhance/fix that style part 
or

if this is too difficult for you you can try to use SHOW-NOW <face> 
to really force 'show' on the specific element.

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.

I guess same is on iOS....the "draw' api is also not using GPU

I don't say you should use OpenGL for DRAW. There is no drawing api 
in Stage3D as well. I was proposing to use AGG to draw to bitmap 
with the best possible quality and let the HW do what it's made for.. 
to move pixels around. Bo understands it. That's actually how are 
modern apps made to have 60fps. To make animations just in AGG will 
not work (and honestly never worked). But maybe I'm too involved 
in animations and for many people would be enough to have static 
content. But that is not for future.

Oldes, I don't argue with you and Bo about that. I think we all know 
the state of this technology. I've already did several prototypes 
of such "engine" so I have some ideas how this could be done for 
R3 it's just matter of prioritizing&time&resources.

I wrote about the drawing apis just so other people know OpenGL is 
not any Messiah if you want to do hi-quality 2d vector graphics in 
realtime.

I'm not against HW acceleration at all. It's just not easy topic 
in this non-ideal programming world as you pointed out.

I see the solution with good high quality rasterizer + HW accelerated 
compositing engine. That should be flexible setup at least IMHO. 
Plus this way also we got the classic 3d api for free.

Ladislav, I agree about the level of activity not being as useful 
if the number of contributors is not specified, but for now this 
will have to do. The way to do this is through some reasonably smart 
scripting that can obtain a better breakdown of posts by user, either 
through scraping or some sort of API, if available.