World: r3wp

hehe, right now... with the cgi in between, I don't think you'll 
get a lot more out of building it in liquid...

haw should the net module work? ?services?

if elixir where ready for release, then, yes it would be a simple 
click and drag... but alas, its not there yet..

it will be direct tcp intercommunication in between nodes.

using encryption if you have those options in your license.

I will try to use the liquid concepts adding attributes to the nodes 
and do a "classical" plugin for the proxy

it should be possible to add an adaptor in order to plug a liquid 
system within a reb service, but thats a later stage.

if I had just a bit more time, I'd be glad to help, but comming back 
from the devcon has but a strain on my time (a lot of time to make 
up at work and at home)

plus I am working on getting a quick Revault demo site ASAP.

Nevr mind, Maxim. Talking about this with you suggested me easier 
way to implement such services and this is an help too!

no problem, I'm happy to help.

During the devCon I "saw" some GUI while you were presenting your 
programs, are those scripts available to the public?

but seeing people's real use cases helps me see where to put the 
time on whatever I do next, and your example shows me that I am dead 
on my priorities  :-)

elixir no, in two weeks  (beg june)

glayout yes.

liquidGL next week.

liquid is online.

all on rebol.org

I am really curios as I cannot come to Paris... Last DevCon was in 
my school so it was simpler to me to attend ;)

I tried your examples on the site

cool, happy to know that people are starting to try out liquid.

I will be giving a lot more tutorials and examples, in the following 
weeks.

I am at a point where all my stuff basically works, I just need to 
start disseminating the information, spreading the word.

and supporting people who use it.

A suggestion: put the working full script as a downloadable file 
(rebol.org or a link from liquid site) at the beginning of the page. 
I did the example step by step following the page and, at the endo 
of my tests I found the full script I colud copy and paste!!!

and it seems, by a strange twist of faith, that I suddenly have A 
LOT more time on my hands... (I'll let you figure out why ;-)

thanks, good idea  :-)  point taken

but then, its possible having done each step helped you understand 
the magic trick  ;-)

when you see just the trick, you usually are clueless ;-)

I think that samples are a must for such kind of stuff. VID, Draw, 
Services, rebcode and similar powerful things lost their momentum 
due to the lack of eaxamples imo

ok, well I have to log off, but I agree.  The liquid part of my site, 
has a usefull simple tutorial, but it needs more advanced examples 
and stuf, and that's where I'm at now  :-)

I Agree, Maxim. I was thinkg the same thing whan I met the script...: 
"Maybe Maxim wanted me to understand the basics before I play with 
this new toy or I won't appreciate it"

it used to be that I was scared the spec of liquid would change too 
much and I would run into support issues, but so far, its remained 
backwords compatible for the last year... and I have implemented 
VERY complex systems using it, so I am now confident its in a state 
of production approval.

I sue similar tricks as a teacher, maybe you made the right choice

sue=use

hehe.

See you

ciao and thanks for the interest... any question you have, I'll be 
happy to answer.

max... i've been studying liquid and how it can be used (or not ;) 
in vid+ (or vid2 or vid3 or whatever we want to call it)

my conclusion is the same as nenad's... it's overkill :) i think 
i can do all that users need to do with just event handling. that 
is, recognizing that in the ui everything is about events. the system 
does not need a network, just direct "links" between elements (call 
them widgets, styles, etc).

from the user pov, it looks like a network, but internally it is 
not. in particular, events don't need to be propagated (this avoids 
the cycle problem altogheter)

i'm interested in examples where this would not work. (i think i 
can reproduce all examples i have seen from you so far, ie. sliders 
attached to fields and so on)

Does it make it easier for ordinary programmers though?

Just in Mozilla: Was reading rss in sage, opened bookmark-editor, 
moved bookmarks, sage was updated. i think liquid is for such things. 
also the wiring can be shown graphically. Have seen that with Visual 
Age did that long ago. If it is well done its not a bad idea. I still 
fear it will be hard to debug, since all this wiring is invisible. 
Or maybe: it was to easy to create for me. BAck in that days i found 
such connetion-stuff cool and created a lot spagethi. (was not using 
VA, that method worked with pure oops too^^)

Later i moved to oberon. Oberon does not use explicit connections. 
Instead each event is broadcasted to everything. WHich may broadcast 
it to its inner parts. I found that to be easier and more flexible.

Well, if we interface to user via a dialect, then it is ok to me. 
The thing is - web is full of various frameworks. I read about them, 
about their ideas, and it is OK. The trouble is, that for the thing 
to be usable, you have to study, what the framework author though 
about, when he/she was creating a framework. And I fear, that way 
too much abstract framework will distract coders, as they will not 
understand, how to extend it, etc.

graham, i believe easier than using liquid ;) on the dialect level, 
you just use "attach" like max does in liquidgl.

I think that VID is nice. Dialected aproach is the way to go, that 
is for sure. I would be OK, if VID would fix some things as - tabbing, 
cursor change, accelerator keys, visual focus representation to widgets, 
disabling/enabling (for business wide widgets), resizing, methods 
for drag & drop etc. Look e.g. at VID's feel - it was abstracted, 
that you have central storage of "feels", but was that abstraction 
used to any good by anyone? I like self-contained styles/widgets 
of rebgui better.

Let's create new VID, which will be both easy to use from user perspective, 
yet easily extensible for developers. That means, that engine has 
to support those basic functionalities from the very beginning, otherwise 
we will be in the trap once again ...

petr, we may not be able to deliver all of that for july (or maybe 
yes, depending on community help), but it's certainly planned and 
will happen