A bootstrap netlet is special to Jnode--it's one of the netlets named on its command line which it initialises when it starts.
It's useful to realise that while a bootstrap netlet is very important, it's is not part of the Jtrix definition. A bootstrap netlet is special to Jnode, which is a command line wrapper (plus more) around Nodality, but the Jtrix definition just defines what nodes and netlets etc should do. It doesn't specify that nodes have to have a command line wrapper any more than it specifies that anything related to Jtrix has to end with ``ix'', so it certainly doesn't specify what command line netlets ought to be able to do.
When a netlet is named on Jnode's command line it can be followed by a number of parameters of the form name=value, where each value is a I/O stream--in practice a file either for reading or writing. In our case we want to read in a warrant which the netlet will then use to access the hello service. It will look like this:
% jnode 203 -netlet-stdio hello3-client.xml warrant-in=hello-warrant.xml Jnode starting... Initialising Nodality... Bootstrap starting starting hello3-client reading hello-warrant.xml for warrant-in: Warrant for service Bootstrap complete netlet:203.0.1: Hello, world, and thank you for using our service ^C %
Bootstrap netlets are useful because netlets cannot choose to access system resources, and hence cannot read files. But whoever runs Jnode can choose to give certain netlets access to selected files, and this is how it's achieved.
In the example above the warrant comes in on an I/O stream, the netlet reads it, binds the service and gets the message. This is all very nice, but it raises some questions.
First, if netlets run in their own sandbox, why are these bootstrap netlets allowed to access these files?
Second, if netlets run in their own sandbox, what kind of mechanism allows them access to these files?
And third, if bootstrap netlets are particular to Jnode, how can we write a netlet which both conforms to Jtrix and still has access the necessary file access?
We'll answer these in order...
First, it's true that netlets run in their own protective sandbox. But bootstrap netlets are allowed this file access because they're being chosen to run by the node's owner (i.e. whoever executes Jnode) and if they don't want those netlets to run, then they shouldn't give them on the command line. Also--and more importantly--the node's owner chooses which files they are given, and they don't have any more file access than that. So access is still very tightly controlled.
Second, while netlets run in their own sandbox there is one exception. This is the external netlet which wraps the node, and that's only because it's a normal application as well as being seen as a netlet by the node. And Jnode is that external netlet. So it's Jnode which looks at the command line, interprets the name=value arguments, and can make them available to the bootstrap netlets.
And finally, how is this achieved? It uses netlet facets, those facets which a netlet offers a node, which the node can find with the getFacets() method of the INetlet interface and can bind with the bindFacet() method. By creating a netlet with the right netlet facet we are effectively offering that facet to any node we happen to be running on--and it still fits the INetlet interface we've seen before. If that netlet happens to execute in a different kind of node, or if it manages to execute in Jnode but not as a bootstrap netlet, then there's no problem--that netlet facet just doesn't get used.
Nik Silver 2002-03-09