On Tue, 15 May 2001, Ian Clarke wrote:
> For those who think that layer #2 should be a front-end to layer #1, all
> you are doing is adding unnescessary bloat. Any smart implementation of
> layer #2 will interface directly with the node, and there will be no
> incentive to use layer #1.
I disagree. Nodes have enough to do already. Layers 2 and 3 should be
implemented as a separate program, in order to prevent duplication of
effort and incompatibilities (which will be hell for client writers).
However, you did convince me that layer 3 makes sense. Many applications
require requesting sets of keys in the background.
Flexibility is a major problem. We should allow clients to submit scripts
for execution (perhaps with guile? python?). The scripts can progress
through arbitrary states and add data to a reply which will be returned to
the client when it checks the status. Then this will be a flexible and
useful tool for client authors.
ClientRunScript
Identifier=myscript
Language=perl
DataLength=43
Data
state("some_arbitrary_state");
for (1..10) {
$uri = "freenet:SSK@foo/bar-$_";
state("requesting $uri");
# insert request code here, also add data to the reply
}
state("done_foobar_arbitrary");
And then the client checks the state:
ClientGetState
Identifier=myscript
EndMessage
NodeState
State=some_arbitrary_state
DataLength=14
Data
some arbitrary returned data from the script
It's an interesting idea. I'd vote for python, myself. :)
--
"...it must be held that third-party electronic monitoring, subject
only to the self-restraint of law enforcement officials, has no place
in our society..." Mark Roberts | [EMAIL PROTECTED]
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
