Tunes

[Francois-Rene Rideau]

>>    For instance, if someone publishes an object,
>> other people may want to "watch" it, so they can update objects
>> based on it.
>> Now "watching" spends resources; whose resources will that be ?
>> How can these
>> be efficiently, yet safely and securely distributed ?
> 
> Wouldn't "watching" be nothing more than checking the original object 
> at a specified interval to see if it's changed in any way, and if so, 
> updating your copy of it?
   "Watching" is not so easy, if the watched object is not yours (e.g. a GNU
copylefted package on the internet), particularly if you require consistency
constraints (i.e. get the most recent software, but require it to work
together and with what you have). Shall the publishing site or the author
spend all the resources by sending you mail ? Will you and other user load
the net with stubborn polling messages trying to determine the version ?
What if someone fakes an update to pirat your machine ? Or just that the
"update" introduces features that make it incompatible with your
environment ?

>>    Another example: we avoid overhead and produce efficient code by
>> producing specialized versions of objects. Now, we still want to be able to
>> change values objects were specialized for (e.g. a real-time animation/game
>> was specialized for fast drawing on the current screen or window settings,
>> but
>> we'd like those settings to be modifiable so that the user can tweak his
>> configuration or even change machines and continue the
>> animation/game/whatever
>> from where he left exactly). So how can we do it and still respect our
>> efficiency and timing constraints ?
> 
> You can't do that unless another module, one that is specialized for
> the settings/computer you're using, is available. The object
> performing sensitive tasks should make a request for the module that
> will best perform under the current conditions and have to use what
> it gets. This could be anticipated by developers. Let's say id
> decides to releast TunesDOOM. It could create specialized modules
> for various computers/video hardware. If you change your hardware,
> the DOOM object could try to retrieve a specialized module from id
> in order to keep performance up at the necessary level.
   Do you mean that each program should come with all its drivers ?
That's DOS, not Tunes. The principle of Tunes is fine grained modularity.
Sure, there should be automatic hardware detection in some installation
module for graphic libraries. But sure those libraries should be completely
independent from other programs that use it. When it is installed for a
computer, Doom would just link to the library that was customized to the
current computer. This would be done transparently to the normal user,
who shouldn't bother. A Doom installed for several computers may memorize
several specialized versions of the code, transparently to the user, too,
but also to the Doom programmer. If Id would like to support hardware that
the library doesn't, it may extend the library. If it requirs functions
that the library can't support efficiently, even as an extension, then sure
the library was bad and should be redesigned anyway.

>>    And when we export an object, what set of annotations should we export
>> together ? How to manage these annotations in a way such that it won't
>> become
>> completely chaotic even though many different users and sub-users
>> customize it with complex dependencies inside those customizations (not to
>> talk about several versions of the "same" objects in different computer or
>> human languages).
>>    More generally, when we want to extract an object from its "specialized"
>> context, how can we adequately distinguish what is the object, what is the
>> specialized context ? What implementation techniques are involved so that
>> this process (including tracking dependencies on all objects abstracted
>> from the context) is not too costly ?
>>    The exact policies for such things is very important as for the system's
>> response and resource hit, but can only be determined by fiddling on real
>> data.
> 
> I'm not clear on what you mean by "what set of annotations." Can you 
> give a specific example of what type of problem you're referring to? 
   Sure. Objects in Tunes are atoms, linked with each other by annotations.
For instance, I could semantically attach to a tree structure the deepness
of the tree as an annotation. Implementation could actually remember it
in an extra field, or compute it each time, or build hash tables for recently
computed values, etc. Annotation is a semantical concept, a formally
specified object, which is what the user wants to achieve, efficiency being
its second criterion.
   Now, when I write some program, I'll define, say, interactive messages
as annotations to program input/output points. I may define them in several
languages, write personal customizations. The same stands for the interface.
And I may add personal "watches" about some objects (for instance, for
debugging). Now, if I have to distribute the object (to the public, a friend,
a business partner, or to clients), I want, for multiple reasons to strip
the program to some coherent package that won't include all my specific and
personal (or source) data that won't interest anyone, or that I want to
preserve. There should thus be an efficient, standard, mechanism to describe
which annotations are "part" of some object, which are external to it.


> Jason Diamond
> diamond@deltanet.com


--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"