On Fri, Mar 31, 2006 at 07:10:02PM +0000, mxbee at i2pmail.org wrote:
> Rather than making all private requests visible globally I think we should
> have 3 different kinds of requests:
>
> (1) strictly private
> (2) private, but globally monitorable
> (3) truely global
>
> (1) and (3) we already have, (2) could be implemented by extending ClientGet
> like:
> ...
> Global=false
> GlobalMonitor=true
> ...
Not a bad idea.
>
> so that
>
> !Global && !GlobalMonitor => (1)
> !Global && GlobalMonitor => (2)
> Global && GlobalMonitor => (3)
> Global && !GlobalMonitor => (3) or Protocol Error
>
> Kind (2) would be basically the same as private requests, but
> SimpleProgress/DataFound/GetFailed would also show up in the global watch
> list.
> For kinds (1) and (2) the application that issued the request is responsible
> for dealing with it when it succeeds or fails, whereas kind (3) indicates
> that the issuing application doesn't want to be bothered by the request
> anymore.
> (1) and (2) would always show up on a private ListPersistentRequests.
> (2) and (3) would also show up for other parties if they WatchGlobal.
>
>
> Examples of use:
> (1) Frost message up/download. There is no use to see those in the global
> queue.
> (2) Any kind of private download that should be displayable (but not
> modifyable) by other apps. For example Frost downloads if Frost is configured
> to handle its downloads itself.
Don't we want it to be possible to pause these/change priority on them?
> (3) Fire-and-forget requests. Eg Frost downloads if Frost is configured to
> let other apps handle downloads.
>
>
> Only dealing with kind (3) in conjunction with a non-local node is
> problematic. We need user intervention once it is done.
My preferred option for dealing with this is to ignore it. FCPv2 is
designed to have the local node running locally; it has disk access on
that assumption; if people want to run it remotely then they can damn
well set up NFS. However this is an unpopular viewpoint, so lets see
what is possible.
> I suggest the following (ClientB being a central monitoring app, like Fuqid):
> ClientA issues a ClientGet{Global=true;ReturnType=direct} and forgets about
> the request.
> ClientB monitors and displays the global queue. As soon as it sees a
> DataFound it alerts the user (eg. by marking the file). (Data still stays on
> the node)
> The user then selects the file and chooses to save it on his local PC.
> ClientB sends a GetData(*) message to the node; the node will reply with
> AllData. The data still does not get deleted from the node.
> Now the user can choose to keep or remove the request. Upon removing
> (RemovePersistentRequest) the node deletes the data.
> (he could also switch to another PC, fire up a central monitoring app there,
> and save it there too/instead)
That's not a bad idea. Of course it's necessary for there to be multiple
central monitoring apps. FUQID and a queue manager page on Fproxy, for
example.
Thanks!
Okay, so what we have is this:
A persistent request with Global=true is assumed to be fire-and-forget.
If ReturnType=disk, then it is truly fire and forget; it can simply be
deleted when it completes. The node doesn't do this however, since
somebody might want to know about it. It's left in the queue until it's
explicitly acknowledged.
If ReturnType=direct, then the node downloads the data into a temporary
space. Then the user is informed, and when he has decided what to do
with the data, he removes it.
Nice!
Given this understanding of (3), is there any need for (2) ?
> (*)(Generally, AllData should only be sent by the node in reply to a (not yet
> existing) "GetData" message, rather than automatically - at least for global
> requests)
We can keep it as it is now for local requests. Clients shouldn't keep
large amounts of data on the node unless they have to, it's anti-social. :)
>
> Preferably all clients should detect (or let the user configure) if the node
> is local or not.
How can we do this?
> Local nodes are unproblematic, the client can always use ReturnType=disk. For
> non-local nodes they would rather use ReturnType=direct.
>
> That way even a completely split scenario is possible, like machine A running
> Fuqid, machine B Frost and machine C the node.
>
> mxbee
>
> PS:
> I really don't mind the non-bundling of Fuqid, actually I prefer it that way
> - with bundled applications many users just forget to watch out for updates.
Thanks, your comments are most helpful.
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20060331/d4c11245/attachment.pgp>
