World: r3wp

There's an approach that I'd like to experiment regarding web UI 
generation. The idea would be to consider the web page as a View 
target and build a View-like rendering engine able to process face 
objets and renders them as HTML. So it would be possible to generate 
HTML UI with VID directly. The DIV tag would be a good candidate 
to emulate a View face.

The events system would be splitted in two parts :


1) A small part in JS on client-side catching keyboards and mouse-events 
and sending them asynchronously to the server.


2) A server-side part emulating the View event propagation engine 
through the face objects hierarchy.

Did anyone already tried such approach ?

Qtask has, I think.

Doc - maybe you could communicate it with Gabriele. IIRc VID3 is 
flexible to generate various outputs. Look model is separated, but 
it would be better to ask Gabriele.

Wait, no. That approach would fall over when you run into network 
latency issues. It would work great on a LAN, but not over the internet.

as for JS, I am not sure it is fast enough. I saw Sun's JS based 
desktop, and it was joke compared to even VID 1 alpha speed probably 
:-)

Keyboard and mouse events happen too quickly, and people expect them 
to be handled quickly.

It's not JS that would be the slowdown - it's the network connection 
to the server.

On the other hand, you could build a View-like rendering engine in 
JavaScript itself.

yes, with Cairo crap instead of AGG, right? :-)

but it is the possibility. Brian - I am not sure Sun's desktop was 
slow because of communication with server - dragging of stuff around 
the screen was slow. So I just wonder, if JS generated UI can be 
as fast as View (which is still not optimised)

but I think that view-like engine could be built

With the DOM for regular UI elements, and Canvas for Draw once it 
is implemented more widely. The browser is a little weak right now, 
but that is improving, finally.

IIRC, when Cyphre did some game for Java enabled cell phone, he created 
small engine emulating faces

JavaScript doesn't have access to Cairo directly in any browser. 
JavaScript is not anywhere near as fast as Java yet.

Brian: true, network latency might be a show-stopper for such kind 
of apps over the internet.

View-like engine in JS : that looks very doable, but I'm afraid the 
result might be too slow. I've worked some time with a rendering 
engine built in JS, and it was just a little slower than native UI, 
but not very scalable (performances dropping rapidly with a growing 
number of "faces"). It was BackBase : http://www.backbase.com.

So maybe the solution would be to handle those events that need fast 
response like typing text in a field, or mouse-over gfx effects, 
on the client-side and send others to the server.

but what is the idea? to have one rebol view app with VID or browser 
UI?

The goal would be to use VID/REBOL to build web applications without 
typing any HTML or JS.

So yes, to make the browser another potential "target" for View apps.

then Gabriele is good target to consider, he might have some ideas, 
as he knows best what VID3 is going to be about. Imo we should skip 
VID2 ...

Doing the VID2( or 3) interfacing is the easiest part ;-)

If we are going to use a JS framework, I insist in using jQuery, 
the core is really mature,fast and stable, it has the syntax that 
more resemble the way we think in rebol. http://docs.jquery.com/Main_Page

livequery, how cool 8)
http://www.learningjquery.com/2008/03/working-with-events-part-1

Brian, no, Qtask hasn't, and that's what i've always been fighitng 
with Reichart about :)

if we don't expect to emulate View 100%, but rather we do a Web VID, 
i think this can definitely be done in JS, with the server only to 
access data.

Will, I'll updated my JSON copy script here with your changes, but 
Romano hasn't been around in a long time, AFAIK, so someone (I guess 
maybe you or me) should get joint ownership of the script on REBOL.org 
to update it.

Do you have a test case for the change?

Should > be in the list of escaped chars? It doesn't look like it 
from the spec. I'll have to check my notes to see if that was added 
for a specific reason.

We are not fighting...fighting would mean I don't agree with you...

example is in the patch above, flikr api returns:
{"name":"Taiwan Panorama \/ \u53f0\u7063\u5bec\u8996\u91ce"}

without the patch it won't work once it encounter "\/" do you really 
need a link?

Ha! I thought it said "Panorama V", not "Panorama \/". :-\

here you go:

probe JSON-to-rebol head clear back tail copy find/tail read http://api.flickr.com/services/rest/?format=json&api_key=45d5d4b7dff9bc653c8eb3e73271c10c&method=flickr.photos.getInfo&photo_id=2279042485
"jsonFlickrApi("

return error without the patch

Yeah, I see the solidus in the spec, though I wonder how it was overlooked 
before. It looks like they've also done away with comments in the 
spec. Is that so?

That is, JSON no longer supports comments.

would be nice if you can take control and update on rebol.org to 
prevent others headaces 8)

I'll get it updated shortly.

Thank you!

I'm checking with Douglas Crockford about what the real rules are. 
None of the examples have the solidus escaped, even though that's 
what the grammar says to do. Once I have answers from him, I'll post 
an update.

I've noticed some websites like Amazon don't seem to have a log out 
/ sign out button any more. What's happening ? How are they doing 
the logout ?

maybe it is just hidden, using cookies? If you have cookie, you are 
auto-logged-on, and the session will end when you close your browser 
session?

reichart, "fighting" is not the right word... i'd say, it's just 
me continuously whining about thing not being this way :)

Will, Here is the answer from Douglas Crockford:


It is optional. It is allowed for the case where JSON is embedded 
in HTML 
SCRIPT, where 
</" is not allowed, but "<\/" is.

There are no comments in JSON."


So, on the parsing side, we should look for it, but on the generation 
side, \/ is really ugly if we generate it everywhere. If we don't 
generate it, you're stuck if you need it, so we probably need a refinement. 
Either that, or just accept the ugliness.


I'm not sure if I want to remove comment support either. Just a gut 
feeling they may come back.

Gab, : )

Gregg, thanks for digging this deeply, I would suggest just adding 
it, no refinements, at the end it is a transport not meant to be 
human readable (unicode escapes aren't more readable ;) so no need 
to think if refinement is needed case by case.

It just makes paths look so horrible. :-) 

Does anyone else here care?