In the meantime I filed a feature / bugreport for each issue. So, don't know if it makes much sense to discuss it here. Anyway...
Matthew Toseland schrieb: > 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. > I assume yes == "arbitrary". >> 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...? > Not necessarily for ignoring them, but for knowing when the node is done throwing persistents at the client and doing eventual post processings. >> 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. > Not necessarily my* requests. I filed a report regarding this [https://bugs.freenetproject.org/view.php?id=1893]. Well-known-name is well known to who? I wouldn' t want to keep track of all names all clients may have in use when there is a better solution. >> 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. > Done so. >> 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. > Done so. >> 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. > Error messages No. Config strings Yes. >> 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? > Good idea. That could do the job. Plus might be aswell that it gets more likely that messages / tooltips / (...) are the same accross clients. >> 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. > True one can ignore it. But IIRC it is not random but "myfile.txt.tmp". Thus I have to handle collisions all the time. ClientGet:"SSK at ABC/myfile.txt" vs ClientGet:"SSK at XYZ/myfile.txt" > 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) Quite a common task when downloading. "SSK at ABC/myfile.txt" is very likely to be different content then "SSK at XYZ/myfile.txt". And even if it is not the use case decides how to handle collisions. If I run a client for downloading, "download again" is most likely to be interpreted as "I want another fresh copy". A mail or board client may have needs to interp it differently. > 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). > That's an alternative. But maybe in this case it would be even handier if the node would not try to rename the temp file in the first place. Why not let the client decide what to do with the file. That is make the Filename field optional and pass the TempFilename along with DataFound? This would give both, the node and* the client free hands to do whatever might be necessary. I know it is messing up the current protocol, and I am truly sorry for that. But the prospect of simplifying ClientGet for disk downloads down to having to pass a directory and only* a directory is to tempting. It would make live of clients so much easier not having to deal with all these error codes and being prepaired to repetetively resend messages. I already filed a feature request regarding this: [https://bugs.freenetproject.org/view.php?id=1894] Thanks, Juergen
