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
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)]
spoon@lists.squeakfoundation.org
-
Craig Latta -
stéphane ducasse