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
...
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.
(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.
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)
(*)(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)
Preferably all clients should detect (or let the user configure) if the node is
local or not.
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.
On Wed, 29 Mar 2006 00:33:46 +0000 (UTC)
Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> I'm sorry about not including FUQID in 0.7. I had planned to; Ian thinks
> it's a bad idea since it's not cross platform.
>
> We need to sort out this issue with the global queue. Is it useful for
> apps to queue stuff to the global queue *which FUQID can watch, but
> cannot usefully remove* ? By "cannot usefully remove", I mean that the
> client app which queued it must deal with it because it cannot be
> returned to a disk file. The alternative is that Frost et al simply
> queue stuff to their own queues rather than the global queue. Another
> option would be the ability to watch larger or more stubborn files on
> all local queues in addition to the global queue... this might make a
> bit more sense; the user could cancel old requests which he will never
> use, and see the progress of files, but the primary responsibility rests
> on the submitting app...
>
> What is your view on this?
> --
> 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: not available
Type: application/pgp-signature
Size: 168 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20060331/fe1f9af6/attachment.pgp>
