Naiad (was "Spoon progress 15 April 2006")

[stéphane ducasse]

Thanks craig I will digest that.
May be you should consider to write a paper on that.
This would help people to cite your work.

Stef

On 19 avr. 06, at 00:23, Craig Latta wrote:

>
> Hi Stef--
>
> > Do you have a description of Naiad?
>
> 	Not a proper one, no. There's just the Spoon mailing list archives 
> [1] and my "position statement" at Dan's request for the modules  
> mailing list[2]. Soon... I'm hoping we can still discuss what we  
> want such a system to do in the meantime, though.
>
> > What is a Naiad module?
>
> 	Currently, it's an object with:
>
> -	an ID
> -	added method IDs
> -	removed method IDs
> -	removed class IDs
> -	a name
> -	a description
> -	an author ID
> -	an initialization block
> -	prerequisite module IDs
> -	component module IDs
>
> 	IDs are all Leach/Salz UUIDs. Two modules, each resident in  
> different object memories, can synchronize their respective systems  
> via remote messaging. The requesting module asks the providing  
> module to synchronize the two systems. The providing module:
>
> -	ensures that its author is defined in the requesting system
> -	has its prerequisite modules synchronize with the requesting system
> -	defines its added methods
> -	removes its removed methods
> -	removes its removed classes
> -	synchronizes its component modules with the requesting system
>
> 	The requesting module, now equivalent to the providing module,  
> runs the initialization block. (Note that the receiving system can  
> now act as a provider to other systems.) The actual system changes  
> made during the synchronization depend on the initial state of the  
> requesting system. Many of the pitfalls of fileouts are avoided,  
> since the author doesn't have to second-guess the initial state of  
> the requesting system. The requesting and providing systems can  
> work through their differences almost entirely on their own. The  
> information exchanged is not static, as with a fileout or similar.
>
> 	Requested methods can define their literals properly in the  
> requesting system, including defining new classes when necessary.
>
> 	I've implemented a system for expressing Naiad commands as URLs.  
> Such a URL, when selected, issues a command to the Spoon system  
> running on localhost. The so-called "path" segment of a link is a  
> text-encoded action, which the local Spoon webserver evaluates.
>
> 	There are several different commands: for quitting Spoon, making a  
> snapshot, installing modules, and so on. A module installation  
> command contains the hostname and port of the machine serving the  
> module, and the module's UUID. The receiving Spoon system uses this  
> information to create a remote-messaging connection between itself  
> and the serving system; the two systems then synchronize themselves  
> via remote messages.
>
> 	See [3] for an example of a Naiad link.
>
> 	One simple way of enabling module discovery is simply to publish  
> lists of Naiad links on webpages, with module cataloging  
> information, and let Google do the indexing. I also intend to  
> create a more integrated discovery system with Spoon systems in a  
> relay architecture, similar to IRC.
>
> > I'm really interested in knowing that and what we could do with  
> them +
> > improving if necessary.
>
> 	Now's a good time to discuss the design. What would you like it to  
> do?
>
> > Are other people welcome to use and build on top of spoon and Naiad?
>
> 	Yes, see [4] (which has been in effect since the first public  
> release, of 14 February 2004).
>
> > How do you see possible collaboration?
>
> 	I'm all for it. :)  Is there something more specific you want to  
> know?
>
> > > Ideally, I'd like the new modules to contain well-factored and
> > > highly-readable expressions of the ideas of the old subsystems,
> > > rather than just blind repackagings, but we'll see... it's  
> tempting
> > > to just imprint things to save time. :)
> >
> > You mean that you would like to rewrite some parts?
>
> 	Yes, particularly the virtual machine implementation. I think it  
> could be much clearer in many places.
>
>
> 	thanks!
>
> -C
>
> [1] http://lists.squeakfoundation.org/pipermail/spoon
> [2] http://minnow.cc.gatech.edu/squeak/5618
> [3] http://netjam.org/spoon/modules
> [4] http://netjam.org/spoon/releases/current/frame.php#license
>
> -- 
> Craig Latta
> improvisational musical informaticist
> www.netjam.org
> Smalltalkers do: [:it | All with: Class, (And love: it)]
>
>