Looking for suggestions/advice

[Marielle Lange]

> <http://www.devarticles.com/c/a/Development-Cycles/Learning-About- 
> the-Graph-
> Construct-using-Games-Part-1/>

Thanks for the link, Xavier. I added it to :
<http://revolution.lexicall.org/wiki/tiki-index.php? 
page=TechniquesGraphDrawing>
A page in the revolution wiki on graph drawing techniques.

>> That isn't to say that I
>> would be reluctant to add new functionality to existing
>> commands. As long as new arguments are optional, it wouldn't
>> break existing functionality. I think it is easier for
>> non-programmers to understand a greater number of simple
>> commands than a small number of complex commands.

> TAOO, my working environment and framework in Rev or MC is just
> like that too but distributed over a growing dozen of "object" class
> stacks each with the object's verbs... There's some 200-600KB of
> scripts available any time for any taoo component. I dont event
> have to look at any script reference ever since it's so obvious
> to listObjects, findFile, relatekeywords, etc...


> No, thank you, Dan and Marielle wanted a clear example of how taoo
> works, and i just can't find the words or a way to make a simpler
> example... This helped quite a bit...

The issue is not to get a concrete example of *what* your xos can do.  
The issue is to understand *HOW* your xos does it.

What I am trying to understand is whether the approach you take is  
useful for any person other than you. I have understood that anything  
can be done. Exactly the same way that about anything can be created  
using html, , laslzo, xul, flex, halo, c++, c, perl, python, etc.  
etc. etc. etc.). What would make the value of your xos system is not  
what it can potentially do... it is how cleverly component  
composition works in your XOS architecture.

Yes, Xavier tends to use the outdated name of object-orientation. But  
what xos is a lot more in line with an infrastructure for rapid  
widget creation or rapid software composition. A lot of persons seem  
to be interested in these issues on the list. That's no surprise,  
revolution has a fantastic potential. What I am personally interested  
in is exploring the possibility to have an online library of handlers  
and calling to them or integrating them on the fly could really speed  
up software development.

put url ("file:" & tfile) into thandler
do thandler

Call could be made to handlers in a central archive. This wouldn't be  
infringing the revolution license in any way because due to the 10  
scripts limit, this would be possible only with a revolution license.  
To transform it into a standalone, something would be needed to  
transform call to handlers stored as text files (or stack or  
whatever) as content of the script.

The problem then is to come up with an excellent model of software  
composition. This takes a lot of work. So, thanks Xavier for all the  
hard work.

Marielle