From Matevz.Tadel at ijs.si  Mon Jun  2 18:15:57 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Mon, 2 Jun 2003 18:15:57 +0200 (CEST)
Subject: [gled-bootstrap] Welcome!
Message-ID: <Pine.LNX.4.44.0306021810350.9957-100000@f9pc03.ijs.si>

Welcome to the gled-bootstrap mailing list.

This mailing list is intended for public bootstrapping of the Gled project.
It will be replaced with more specialized lists when they become
necessary.

You're welcome to post any questions, comments or suggestions to this 
list.

To subscribe, visit: <http://www.gled.org/listinfo/gled-bootstrap>

Cheers,
matevz

-- 
---------------------------------------------------
 Matevz Tadel,          Email: Matevz.Tadel at ijs.si 
 Department of Experimental High Energy Physics F9 
 Jozef Stefan Institute,  Jamova 39,  P.o.Box 3000 
 SI-1001 Ljubljana, Slovenia                       
 Tel.: +386-1-477-3454        Fax: +386-1-425-7074 
---------------------------------------------------


From Matevz.Tadel at ijs.si  Tue Jul  8 14:11:35 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Tue, 8 Jul 2003 14:11:35 +0200 (CEST)
Subject: [gled-bootstrap] viewcvs installed
Message-ID: <Pine.LNX.4.44.0307081407320.12704-100000@f9pc45.ijs.si>

Hi,

the viewcvs tool for browsing of the CVS repository has been installed.
You can access it at <http://www.gled.org/cgi-bin/viewcvs.cgi>.
It is also linked from the /download/ page.

Enjoy,
matevz



From Matevz.Tadel at ijs.si  Tue Jul  8 14:36:26 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Tue, 8 Jul 2003 14:36:26 +0200 (CEST)
Subject: [gled-bootstrap] CVS news
Message-ID: <Pine.LNX.4.44.0307081411410.12704-100000@f9pc45.ijs.si>

Hi,

There are some new additions in the cvs:

1) demos have been checked in; for each libset you can get them by:
   cvs co demos/<libset>
   or ... if you want to grab all of them:
   cvs co demos

2) GledCore: a fix in Saturn initialization;
  	     stamping methods in ZGlass and ZList are now virtual

3) Geom1: new classes WSSeed and WSPoint; see WS_demo.C in demos/Geom1
   Using these classes you can produce axially symmetric curved "tubes".
   You might find it hard to believe, but this was the original goal of 
   the Gled project: to allow several users to cooperatively edit such
   shapes. For an example see: 
   <http://www.gled.org/screenshots/img/weaver_symbol1.png>

Any feedback welcome ...

Cheers,
Matevz



From jan.javorsek at gled.org  Fri Jul 18 17:26:57 2003
From: jan.javorsek at gled.org (Jan Javorsek)
Date: Fri, 18 Jul 2003 17:26:57 +0200 (CEST)
Subject: [gled-bootstrap] Proposal: FTP layout and distribution changes
Message-ID: <Pine.LNX.4.21.0307181612450.993-100000@siyan.ephra.si>

I propose a makeover for the gled source distribution and some changes to
the FTP directory layout to make the software easier for beginners.

                                -"Unnecessary complications are repulsive"


1. Source distribution
----------------------

* Make a toplevel Makefile for gled, as a wrapper for mecca, with echos
telling about basic mecca usage. Simplify gledimp using that.

* In the source distribution, rename gled-build.tgz to gled.tgz, and add
at least the core libset, or maybe all of basic libsets to it, to make
source builds easier.

* Alternatively, make gled.tgz and gled-withlibsets.tgz, or something of
the kind.

* Do something smart with gled-run: as we both know, it is a non-trivial
issue, best resolved with a new distribution.

* Change both gled-build and gled to use top-level directories with
version numbers and/or release dates.

* Make a README for the source distribution directory, and an INSTALL
symlinkg to the Gled_for_the_Imapatient in the toplevel directory.

* Make readme's in various parts (libsets, for examples) all uppercase for
better visibility.


2. Binary distributions
------------------------

* I would be prepared to shorten gledimp further by providing a perl
wrapper script for both binaries, to allow people to just unpack and type
gled. The script should see where it is located, set the paths for gled,
check if root is at the expected place (for the gled+root pack) and croak
otherwise, then write everything to a ~/.gled script (including the gled
version and date, to allow for a new run after a new release) for next
time, and run the binay. I can even write it for you if you'd like that :)
Better, I _will_ write it, using your ParseConfig for consistency, just
mail me any special wishes.

3. Ftp server - minimal change
------------------------------

* rename directories to more self-explanatory names:

  internal/       -> source/
  external/       -> required_software/ or software_dependencies/
  external/src/   -> required_software/source/
  external/dist/  -> required_software/binary/
  packs/          -> binary/
  demos/          -> demos/
  libsets/        -> libsets/  possibly with a contrib/ subdirectory
  libsets/binary/ -> binary @=symlink=> binary/libsets/
  libsets/source/ -> binary @=symlink=> source/libsets/

* In the future, when we get RPM and DEB package support, we should
make toplevel directories for RPM and DEB, fix interdependancies, prepare
-source and -dev packages, and enjoy automagickal installations.

* In each gled-release directory, make a top-level directory named
distribution-tools/ and put all distribution-building tools there
(ParseConfig, build.pl, build.rc build-config pack.pl). Users don't need
to bother if those. It is just for the curious.

* Add a text version of gledimp (Gled for the impatient) to the
gled-release directory, name it Gled_for_the_Impatient and make a symlink
named INSTALL.

* Change the readme_*_auto files in packs: make readme UPPERCASE and add
some comment inside to make them self explanatory, or add a directory
README

* Change toplevel README to update current status, with ample pointers to
INSTALL _and_ http://www.gled.org/docs/html/gledimp.html


4. FTP server - bigger change
-----------------------------

It might be worth considering a different hierarchy for the FTP
repository, following the distribution package repositry logic where you
have one directory for binary packages, with subdirectories for different
architectures (or distributions or distribution releases), another for
source packages, perhaps a third one for raw source archives (tgz), etc.

>From the user's point of view, he/she has to navigate to the
desired directory and pick the top item on the list (the current thing).

>From the implementation side, we have to get all the distribution logic
for the packaging systems anyway.


5. FTP server - WWW interface
-----------------------------

And finally, we need a nice stable list of links on the download page, so
that lazy users can simply click on the desired thingy, have it downloaded
and fire away.



Please, do comment!

Best etc.,
-j.





From Matevz.Tadel at ijs.si  Tue Jul 22 13:41:45 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Tue, 22 Jul 2003 13:41:45 +0200 (CEST)
Subject: [gled-bootstrap] CVS news: POSIX threads and Textured SMorphs
Message-ID: <Pine.LNX.4.44.0307221314490.29321-100000@f9pc45.ijs.si>

Hi.

I've just checked-in the latest developments. In particular:


1) gled-build:
--------------

new options for configure;

project7 can be configured to lock lenses in set/get methods (until now 
set methods were always locked, get methods never). Now the default is to 
lock in both types of methods ... so watch for deadlocks.


2) GledCore:
------------

Gled threads should now be POSIX compliant (used LinuxThreads specific 
features before). This was the only obstacle for portability to other 
systems. If anyone has the possibility ... I'm really interested in 
getting gled to work on solaris and cygwin. (g++ is still a requirement).

Server code for accepting connections has been rewritten into a proper 
protocol. I need that for a proper implementation of user authorization.

Several other minor fixes and beautifications.


3) Geom1:
--------

SMorph can now be textured by a ZImage (Mercator projection).

ZImage is extended to hold GL environment texturing parameters.

demos/Geom1 have been updated to show off new capabilities.

Example: <http://www.gled.org/screenshots/img/geom1-images-22-7-2003.png>


That's all ... see ChangeLogs for details.
Enjoy!

Cheers,
matevz



From Matevz.Tadel at ijs.si  Tue Jul 22 13:59:26 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Tue, 22 Jul 2003 13:59:26 +0200 (CEST)
Subject: [gled-bootstrap] CVS news: POSIX threads and Textured SMorphs
In-Reply-To: <Pine.LNX.4.44.0307221314490.29321-100000@f9pc45.ijs.si>
Message-ID: <Pine.LNX.4.44.0307221344200.29321-100000@f9pc45.ijs.si>

Yow!

I had this funny feeling that I forgot something ... so here it is.

While playing with threads I noticed that NPTL implementation of posix 
threads that ships with RedHat 9 DOES NOT work properly. I managed to 
trace it down to pthread_cond_signal which blocked the calling thread. 

I'm saying that I managed to track it down because gdb dies a horrible 
death on rh-9 with NPTL and linux 2.4.20-xyz (if that matters) ... and 
this called for some printf debugging.

Anyway ... if you want to run non signal-safe threads on RH-9 (see
gledarch, the chapter on thread support is actually written) then DO NOT
use NPTL. A line like:
export LD_PRELOAD="/lib/libc.so.6 /lib/libpthread-0.10.so"
should do the trick.

Hopefully this will be fixed soon.

Cheers,
matevz



From Matevz.Tadel at ijs.si  Tue Jul 22 14:48:44 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Tue, 22 Jul 2003 14:48:44 +0200 (CEST)
Subject: [gled-bootstrap] Proposal: FTP layout and distribution changes
In-Reply-To: <Pine.LNX.4.21.0307181612450.993-100000@siyan.ephra.si>
Message-ID: <Pine.LNX.4.44.0307221409460.29321-100000@f9pc45.ijs.si>

Hi,

I agree that ftp layout is cryptical if used without gledimp. Also ... 
most of the proposed changes are reasonable ...

> 1. Source distribution
> ----------------------
> 
> * Make a toplevel Makefile for gled, as a wrapper for mecca, with echos
> telling about basic mecca usage. Simplify gledimp using that.
> 
Hmmph ... I would even prefer a true Makefile generated by configure. The 
main reason for mecca's existence is that i couldn't get make to 
"properly" propagate -j options to sub-makes (from a hand written 
makefile).

> * In the source distribution, rename gled-build.tgz to gled.tgz, and add
> at least the core libset, or maybe all of basic libsets to it, to make
> source builds easier.
> 
This is aggregation for sake of simplicity. The binary packs are provided
to make it easy for people to see what we're doing. In the source case ...
if someone has a trouble unpacking two tarballs or cvs-checkouting two
packages then the whole episode is most probably not going to be a milk 
run.

> * Alternatively, make gled.tgz and gled-withlibsets.tgz, or something of
> the kind.
> 
> * Do something smart with gled-run: as we both know, it is a non-trivial
> issue, best resolved with a new distribution.
>
gled-run is a top level directory for installing binary libsets and it IS 
included in all binary packs. if you insist ... i could simply hide it 
from the ftp and only use it internaly for building the distributions.
 
> * Change both gled-build and gled to use top-level directories with
> version numbers and/or release dates.
> 
Reasonable.

> * Make a README for the source distribution directory, and an INSTALL
> symlinkg to the Gled_for_the_Imapatient in the toplevel directory.
> 
I think this is done ... see gled-build.tar.gz

> * Make readme's in various parts (libsets, for examples) all uppercase for
> better visibility.
> 
OK

> 
> 2. Binary distributions
> ------------------------
> 
> * I would be prepared to shorten gledimp further by providing a perl
> wrapper script for both binaries, to allow people to just unpack and type
> gled. The script should see where it is located, set the paths for gled,
> check if root is at the expected place (for the gled+root pack) and croak
> otherwise, then write everything to a ~/.gled script (including the gled
> version and date, to allow for a new run after a new release) for next
> time, and run the binay. I can even write it for you if you'd like that :)
> Better, I _will_ write it, using your ParseConfig for consistency, just
> mail me any special wishes.
> 
Hmmph ... quoting from gledimp for binary install<<FNORD
wget -q ftp://ftp.gled.org/current/packs/gled-base-full-rh7.3-gcc2.96.tar.gz
 tar xzf gled-base-full-rh7.3-gcc2.96.tar.gz
 cd gled-base
 . binenv.sh
 gled hello_gled.C
FNORD
Is this really that bad?

> 3. Ftp server - minimal change
> ------------------------------
> 
> * rename directories to more self-explanatory names:
> 
>   internal/       -> source/
>   external/       -> required_software/ or software_dependencies/
>   external/src/   -> required_software/source/
>   external/dist/  -> required_software/binary/
>   packs/          -> binary/
>   demos/          -> demos/
>   libsets/        -> libsets/  possibly with a contrib/ subdirectory
>   libsets/binary/ -> binary @=symlink=> binary/libsets/
>   libsets/source/ -> binary @=symlink=> source/libsets/
> 
OK ... I agree ... internal/external/packs are poor names.

> * In the future, when we get RPM and DEB package support, we should
> make toplevel directories for RPM and DEB, fix interdependancies, prepare
> -source and -dev packages, and enjoy automagickal installations.
> 
> * In each gled-release directory, make a top-level directory named
> distribution-tools/ and put all distribution-building tools there
> (ParseConfig, build.pl, build.rc build-config pack.pl). Users don't need
> to bother if those. It is just for the curious.
> 
ok
> * Add a text version of gledimp (Gled for the impatient) to the
> gled-release directory, name it Gled_for_the_Impatient and make a symlink
> named INSTALL.
> 
ok

> * Change the readme_*_auto files in packs: make readme UPPERCASE and add
> some comment inside to make them self explanatory, or add a directory
> README
> 
These readme's are auto generated by the build process ... we can put into
them anything that exists in build-config.

> * Change toplevel README to update current status, with ample pointers to
> INSTALL _and_ http://www.gled.org/docs/html/gledimp.html
> 
well yess ... it would be even worse without that.

> 
> 4. FTP server - bigger change
> -----------------------------
> 
> It might be worth considering a different hierarchy for the FTP
> repository, following the distribution package repositry logic where you
> have one directory for binary packages, with subdirectories for different
> architectures (or distributions or distribution releases), another for
> source packages, perhaps a third one for raw source archives (tgz), etc.
> 
> >From the user's point of view, he/she has to navigate to the
> desired directory and pick the top item on the list (the current thing).
> 
> >From the implementation side, we have to get all the distribution logic
> for the packaging systems anyway.
> 
Well ... we're not exactly ftp.debian.org ... yet ;)

> 
> 5. FTP server - WWW interface
> -----------------------------
> 
> And finally, we need a nice stable list of links on the download page, so
> that lazy users can simply click on the desired thingy, have it downloaded
> and fire away.
> 
I agree ... gledimp was meant to be that ... but then it got too long.
The /download page should hold the relevant instructions from the imp.


I propose that we make release 1.2.1 in the coming days ... there are
quite some new additions in CVS anyway. Besides I will begin implementing
user authentication and MIR authorization real soon now and having a
release before such a major change seems reasonable.

Enjoy,
matevz



From Matevz.Tadel at ijs.si  Wed Jul 23 14:43:26 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Wed, 23 Jul 2003 14:43:26 +0200 (CEST)
Subject: [gled-bootstrap] More standard build procedure
Message-ID: <Pine.LNX.4.44.0307231435470.1426-100000@f9pc45.ijs.si>

Hi.

configure now produces a proper Makefile, mecca and mecca.rc have been 
removed from gled-build.

configure takes a new option:
# Libsets to build; can be <file:[filename]>, <auto>, <auto-prompt> or
# ':' separated list of libset names
libsets		=s	.	LIBSETS		"<auto-prompt>"

The build_libsets file has been removed as well.

The auto options scan the directory for top level directories with 
Capitalized names (CVS is grepped out).

auto-prompt displays the list of directories and waits for user 
interaction. Currently, this is the default.

Changes are in the CVS.

Cheers,
matevz




From Matevz.Tadel at ijs.si  Wed Jul 23 17:34:02 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Wed, 23 Jul 2003 17:34:02 +0200 (CEST)
Subject: [gled-bootstrap] GL texture handling & ZImage
Message-ID: <Pine.LNX.4.44.0307231714100.1426-100000@f9pc45.ijs.si>

Howdy,

I have a question about how GL handles textures as I suspect that ZImage 
is written rather stupidly. What it does:

1) ZImage loads the texture (using DevIL)
2) its GL Rnr binds the texture and calls glTexImage2D
3) the image remains resident in devil

Now ... does GL copy the texture to its own memory or not? Because if it 
does ZImage is terribly inefficient by holding two copies of each image at 
the same time.

The thought occurred to me while staring at the third parameter to
glTexImage2D, namely the internalFormat, which is hard-coded to 3 (GL_RGB)
in ZImage_GL_Rnr. This probably sux big time ...

What, I guess, should be done is the following:

1) Add a member variable specifying internal format to ZImage and 
implement at least the most basic values (like GL_RGB, GL_RGBA, some more 
packed formats and basic luminance/alpha formats)

2) have an option load-on-gl-bind for ZImage so that an image can get
loaded, pushed to gl and deleted when file or internal format are changed.

How expensive are the glTexParameter calls? Is it worth having an 
alternate timestamp for them or they can safely be called on each render 
pass? (for setting min/mag filters and texture wraps)

Comments welcome ...

Cheers,
matevz



From jan.javorsek at gled.org  Sat Oct 25 10:21:56 2003
From: jan.javorsek at gled.org (Jan Javorsek)
Date: Sat, 25 Oct 2003 10:21:56 +0200 (CEST)
Subject: [gled-bootstrap] Locators
Message-ID: <Pine.LNX.4.56.0310251010080.12762@siyan.ephra.si>

Yow! Let's start using this list...

We had a discussion on locators. From the gledgui one can inferr that
"point" and "mark" in the Nest are examples of locators, and perhaps
"mouseunder" could be considered a locator too. It is also rather obvious
that the value of a locator can be a lens, but I think the _real_ value of
locator is in fact "first lens in this ZList" or "the ZList this link is
pointing to". Please correct me if I am wrong, and expand on this a bit.

If this understanding of locators is correct, locators could in fact be
very well used for constructs such as (pseudocode):

	locator = pupil->get_link(lens_under_crosshair);
	dereference(locator)->call_method(<method_name>);

It would in fact allow for construction of interesting context-dependent
constructs. If you remember our yesterday's conversation on the usage of
name maps for keybindings, this kind of locators in combination with the
method_name to method_id mapping we now have, could solve the trick for
very general and customisable GUI solution. If we have widget layouts,
window embedding, customizable keymaps and context-dependent construcst
with locators, what are we still missing? (Ok. A lot of work.)

Then again, I might be deluding. Comments?

-j.                                                                            !


From Matevz.Tadel at ijs.si  Sun Oct 26 17:35:54 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Sun, 26 Oct 2003 17:35:54 +0100 (CET)
Subject: [gled-bootstrap] Locators
In-Reply-To: <Pine.LNX.4.56.0310251010080.12762@siyan.ephra.si>
Message-ID: <Pine.LNX.4.44.0310261211310.1569-100000@f9pc45.ijs.si>

Hi,

> We had a discussion on locators. From the gledgui one can inferr that
> "point" and "mark" in the Nest are examples of locators, and perhaps
> "mouseunder" could be considered a locator too. It is also rather obvious
> that the value of a locator can be a lens, but I think the _real_ value of
> locator is in fact "first lens in this ZList" or "the ZList this link is
> pointing to". Please correct me if I am wrong, and expand on this a bit.
> 

First read the scarce information at:
<http://www.gled.org/docs/html/gledarch.html#eye>
Then consider GledCore/Eye/FTW.h, where the Locator structure is defined.

I try to think of locators as cursors into the object graph which are only 
relevant at the viewer/GUI level.

Locator has no real value beyond its position within a FTW_Nest.
The _real_ value is CONTEXT DEPENDENT, that is, the method, that requires 
the locator services has to query the locator and see if its state meets 
the needs of the service.

See FTW_Shell::X_SetLink(FTW::Locator&) and other FTW_Shell::X_* methods.
Note that Source and Sink are defined in a context of a shell/eye, while
target is nest specific (each shell can spawn arbitrary number of nests).

(These are the methods that actually get called in response to stuff from 
the Nest's Action menu.)

> If this understanding of locators is correct, locators could in fact be
> very well used for constructs such as (pseudocode):
> 
> 	locator = pupil->get_link(lens_under_crosshair);
> 	dereference(locator)->call_method(<method_name>);
> 

Well ... that's what you will see in the above code ... only properly 
dressed up to produce and emit MIRs.

> It would in fact allow for construction of interesting context-dependent
> constructs. If you remember our yesterday's conversation on the usage of
> name maps for keybindings, this kind of locators in combination with the
> method_name to method_id mapping we now have, could solve the trick for
> very general and customisable GUI solution. If we have widget layouts,
> window embedding, customizable keymaps and context-dependent construcst
> with locators, what are we still missing? (Ok. A lot of work.)
> 

Yess ... a shell could have a locator that would point to the current 
key-press demangling NameMap. But, on the other hand, it could have a link 
to it (and that seems a cleaner option). The locators could be used 
internally for construction of key-press chains ... should really think 
more about that to come to a definite conclusion.

BUT: The real pain comes at the end of the command sequence (where the
action should be taken, e.g. creation of a mir or some change in a GUI
state). How do you represent the action and its arguments and how do you 
retrieve them from existing GUI state and class catalogues?

I guess one could come up with certain number of usage patterns that would
cover most (or just some?) of the cases one is interested in ... but i'm 
pretty sure it wouldn't be a milk-run.

Please note that currently all object-graph modification methods (Nest's 
Action menu) and Shell/Nest state control methods are hard-coded using the 
simple FLTK's short-cut mechanism. One should dissect the whole shell 
architecture and have GUI methods register by "name" or "tag" and then 
re-bind them via some subscription mechanism.

> Then again, I might be deluding. Comments?
> 

Well ... I would really like to have some method of connecting keypresses
and picking in the Pupil (GL window) with locators in the Nest.

But this is just adding fuel to the fire ... Gled's GUI will have to 
undergo a major revision to become modular and easily extensible.

we could start working on that once that 1.2.2 is out. i have almost
finished authentication and authorization infrastructure. must clean-up
the code and write the documentation ...  i guess i could get it out in
two weeks. but having an approximate idea of what we want would be great 
... so let's continue this discussion and see where it takes us.

Cheers,
matevz



From Matevz.Tadel at ijs.si  Tue Nov 18 11:09:52 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Tue, 18 Nov 2003 11:09:52 +0100 (CET)
Subject: [gled-bootstrap] Release 1.2.2 is nigh
Message-ID: <Pine.LNX.4.44.0311181053440.23684-100000@f9pc45.ijs.si>

Hi!

I've finished the core changes for 1.2.2:

* authentication & authorization, see http://www.gled.org/docs/auth/
* synchronous MIR execution with arbitrary return datagram
* preliminary HTML class documentation

The stuff is available from CVS, ChangeLogs should give you the general 
idea. There is a problem with moon start-up on multi-processor machines 
... i'll investigate it and try to fix it ... then i'll move on to 
building 1.2.2.

1.2.2 should be out before the end of the week ... hopefully. I'm
using the following versions of external software (and will build 1.2.2 
against them):
ROOT: 3.10.01
FLTK: 1.1.14
Other packages remain the same.

Please ... give it a try and report any problems.

Cheers,
matevz





From Matevz.Tadel at ijs.si  Thu Nov 20 16:16:30 2003
From: Matevz.Tadel at ijs.si (Matevz Tadel)
Date: Thu, 20 Nov 2003 16:16:30 +0100 (CET)
Subject: [gled-bootstrap] Release 1.2.2 is out
Message-ID: <Pine.LNX.4.44.0311201606100.23195-100000@f9pc45.ijs.si>

Hi!

1.2.2 is out. With the three major changes (authentication and
authorization infrastructure, synchronous MIR execution and HTML class
documentation) I believe this is an important step towards a true
usability of Gled.

There are a few incompletenesses in Gled that prevent me from
advocating it to a wider comunity. Last two weeks, during the final
stages of 1.2.2 preparation, I gave this a good deal of thought
... and came up with the "Things to do after 1.2.2" (see below).

I would like to see all of these things nicely done and finished in
1.3.0. It would be great to have some improvement on each of these
topics in every new release.

Feel free to comment or add new items to the list.

I'll submit the release to FM now ...
Enjoy,
matevz


========================
Things to do after 1.2.2
========================

ZQueen
======

Proper handling of dependencies.

A better mechanism for mirroring of queens. Now the request goes via
FireKing which is unnecessary. The beam-result request and
Mir_exchange_session could be used with many advantages. This would
require a queen-loading thread (or threads) to be operating within a
Saturn.

Better object space management. Probably the queens object space
should be composed from chunks of certain size with each chunk knowing
its number of used/free IDs and possibly a list of free ids. IDs
should be reused as late as possible.

Deletion of objects. This is absolutely crucial (now objects can not
really be deleted, they are just moved to Orphanage of their
queens). The main problem with object removal is that local object
spaces on lower Saturns can reference a given object without the
master knowing anything about it. Such objects should be migrated to
some other (local) queen.

A lens will first be marked for deletion and will refuse to be linked
to or added into a list. When reference count for sun-space reaches
zero, the lens can be migrated or actually deleted.


GUI
===

The main goal is to have a custom top-level view of a given lens that
can include widgets belonging to lens's links and list members.  There
is a need for special mechanism for instantiation of such views as
they will form the backbone of the true Gled GUI. The current GUI will
be renamed to Gled Monitor.

There are other minor things that cross my mind:

1) Drag&drop support

2) Intermixed data and link-members in the FTW_Nest

3) MIR creation/control widget (absolutely needed for calling methods
that take any non-context arguments)

4) Pupil enhancements: selection, attached camera, key-control,
additional information displayed in the overlay (possibly interactive)

5) Generick locators that can be used by nests, pupils and custom
top-level views
.

Common files / replica management and access
============================================

This needs to be thought out thoroughly. A simple implementation of
FileQueens and FileSystemQueens should precede any final design.


Concrete examples
=================

1) Cluster monitor

2) Visualization of simulated elementary particle interactions

3) Presentation engine


ZMIR
====

MultiMIRs: a list of MIRs with alphas from the same queen

There are some terminologickal troubles here: MIR is a method
invocation request and it can be of two types: beam or flare. Not
good. MIR is not light ... the covering structure should have
something to do with light. It should be sth like Ray, but it can't be
Ray because Rays are sent from Saturns to Eyes as
callbacks. Hmmph. Could rename Ray to Photon but on the other hand i'm
quite happy with Rays being the thing that reaches the Eye.

The word "mir" in old slavic languages meant peace. There is another
word "mjer", pronounced only slightly diferently, that means world
... or better still ... all that extends around us.

Now, if we ever want to have a symmetric handling of MIRs and
MultiMIRs, than thay must have a common base or a wrapper class that
should contain the routing information (recipient, caller,
result-recipient). This is fine, because those actually don't belong
to MIRs. Or they equally well correspond to a MultiMIR.

To cut the long crap short: a covering structure for MIRs is
needed. It's main function will be to contain routing information and
to provide an ordered access to the actual MIRs. This is painfull
because we still need a simple and direct mechanism for creating
simple MIRs.