Wiki follow-up

["FBK" <rainhard.kofler@xxxxxxxxx>]

Ok, a wiki seems not so interesting to you, maybe I should tell you why I
thought of this:

I am a software developer for the local cancer research institute. I've been
working with Java and C++ in the past, but recently got to know the Ruby
language (http://www.ruby-lang.org), and it has become my tool of choice.

Now when I stumbled across ZigZag and your impressive GZZ and XSL/JavaScript
implementations, I thought this is it!: ZigZag has changed the way I think
about programming completely, as it allows me to model my apps in terms of
Lego-like hyperspatiality, in contrast to custom data structures that come
creeping in without such a generalization of structure. I feel that ZigZag
is a revolutionay concept for enduser applications, and it's as valuable to
a software developer.

I'd like to do a Ruby version of ZZ. Ruby is a pure OO language, and is
completely dynamic; I can add methods, variables at runtime and can even
change the inheritance hierarchy of a class at runtime (well if I NEED to:).
Remote objects come for free, so there's no need for compiling RMI stubs
etc. And it can be picked up by a programmer in a few days and it is fun to
work with. I think this is a perfect match with ZZ.


What I'm planning to do with Ruby and ZZ:

I've been using the Frontier scripting environment
(http://frontier.userland.com) for a while. It's very similar to the "Source
code in database" project mentioned on this list recently: The system
consists of a hierarchy of objects. Objects range from booleans and integers
etc. to plaintext and  XML documents and binary objects, and also executable
scripts. All objects exist in a global namespace, that is mapped
transparently to the programming language, are persistent, and can be viewed
at any time in a tree view. It is in fact similar to GZigZag's visual power,
however is constrained to a parent-child hierarchy. But its visuality and
ability of direct manipulation of the objects that make up an app makes it
far superior to most scripting and programming environments (in fact
superior to all envs I've seen so far)

So I am planning to take the ZigZag structure to such a system, made in
Ruby, at first. It would allow for prototyping of complex applications in
days, if not hours, as the system's basic blocks are very limited and the
power is in their connections, not neccessarily in custom behavior, but you
know that already.


I've been reading the documentation I could find from your efforts, and also
the source code. However, since I am not directly involved in your
discussions, many of your design decisions and current directions are
unclear. So I'd like to ask you if you are interested in defining a basic
model for zigzag aware applications together (I know you are already doing
this on this mailing list, but I can't get an overview of the architecture.)

Currently I am thinking about the basic blocks of the system:

- Cell data storage. In your source code I've seen that all data is stored
as strings and then casted to ints and booleans for example (in Clang I
think). So should we define a set of basic data types and binary data,
tagged with MIME types? (Maybe we could make this similar to the XML Schema
datatypes http://www.w3.org/TR/xmlschema-2/)
This way ZZ applications could work with native data types very
transparently.

- Cell and dimension identifiers: I've read many different formats for these
and don't know what is the state of the art.

- Space identifiers, local and remote

- Preflet definition and resolution, related to identifiers

- Protocols for remote access of spaces, related to the preflets.

- Paths and selectors. Using ruby one could map these directly to the
language level, as ruby objects have a method_missing method, that is called
for all methods that are not implemented in an object

I could invest much time in this effort, and want to do it. I will start
with the basic parts, that is cells, dims, spaces and slices,
synchronization, remote spaces, spaces-in-spaces etc. I know these things
can be defined independent of a programming language, and I'd like to do so.

I know you've already addressed these issues in your applications, and will
probably not want to do this again, however if you are interested in working
out the structure in a platform-independent way I would be very pleased.

Bye

Manuel Simoni