On Thursday 22 November 2007 12:13, Juergen Urner wrote: > Hello, > > Quite a list, but I got some some notes / issues regarding Fcp-2.0. > Instead of flooding > the bug tracker with minor issues I thought I better bundle them and ask > for advice > (Node #1075 r15872M) > > > 1.) PersistentGet > ...the node sends a PersistentGet message as soon as a connection is > established for > each request still in the queue.
Yes. The purpose is to remind the client of all the requests it has started and not cleaned up after. The client is supposed to delete those persistent requests which it has no further use for. > > a. the order in wich these messages arrive, should I assume it is arbitrary > or is it in request insertion order? Yes. > > b. is it intentional that listing is not followed by an > EndListPersitentRequests > message? As far as I can see, this would allow clients to do clean post > init processing. "Clean post init processing" = ignore all the messages ? They're not supposed to ignore all the messages! IIRC we send a full status for each request, so it is clear that the request is finished...? > > c. a minor point in relation to the initial listing of persistent requests. > Maybe a bit paranoid, but some client may have left an unknown number of > requests > laying around for the next client to run into. Somehow I would feel > better if I could > tell the node to only list a a specified set of requests and forget about > all others. This is why we have the Name field in the ClientHello. They are *your requests* if your application is well-written and uses a unique and well known Name. > > d. MaxSize and BinaryBlob fields are not passed. This could make it hard > in some cases > to resend a message without keeping track of the initial message across > conncetions. File a bug for this one. > > > 2.) A suggestion on identifiers. > As far as I can see the only way to process is to be prepaired to resend > a message > to handle IdentifierCollisions. Maybe it would allow clients to do > cleaner processing > if the node could be explicitely queried for identifiers. A single Name is a single client, full stop. We only allow one simultaneous connection with the same Name. However, on the global queue, this is not the case: many clients can be accessing it at once. So on the global queue, probing for an identifier would not make sense. On the client queue, it might make sense, although it would undoubtedly be faster to just send the request and retry it if necessary. File a bug if it simplifies your client. > > 3.) I already asked this question on Frost regarding translations and > client / node > locale. Why not let the client tell the node wich locale to use in a > connection? IIRC > nextgens responded something like: error messages are intended to be > used by > programmers only. At the moment FCP error messages aren't localised as far as I know. > > Coding a bit deeper into Fcp I noticed all the strings being passed in > ConfigData messages > and feel like restating my point. Why double effords (horror ;-)when all > these strings are > already translated so nicely. Was: my american friend wants to talk to > the greek node on > my machine. The config strings are localised but not much else. If you want l10n for the config strings, we could pass in the locale for that specific family of commands? > > 4.) from my wishlist: handle filename collisions. The node checks for > TempFilename > collisions for security reasons but IIRC does not check for Filename > collisions when the > request is complete. Anyway.. a flag would be nice indicating how to > handle collisions of > either one. Something like "HandleTmpFilenameCollisions=report | rename", > "HandleFilenameCollisions=report | rename". Where rename does an > automatic rename > to "myTmpFilename (1)" / "myFilename (1)", reporting the final names on > PersistentGet > and DataFound. I know, "blah (1)" == ugly, but IMHO but that's what a > client has to do > anyways. Ignore the tempFilename, we've got rid of it iirc. Data is written to a random filename related to the final filename, and then renamed. Well, if the file already exists, it could mean it was a bad filename, or it's already been downloaded by another client. The desired handling could be anything from rename it (IMHO this is not likely to be useful very often) to dump the old data to keep the old data in temporary space. The easiest thing is if the rename fails, we just tell the client where the data is now (the random temp filename). > > Juergen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20071128/27675af8/attachment.pgp>
