On Wed, Nov 01, 2006 at 08:17:35AM +0100, bbackde at googlemail.com wrote: > You don't want to understand me. > > My point is that I want a clear design from you. I want that any > client application is able to check if the key must be requested with > or without the filename.
Easy. If it has a filename, it must be requested with the filename. If it doesn't, it must be requested without a filename. Right now you are still able to add arbitrary path elements, but this will not be the case forever. The problem is that making the change will break back compatibility; apps must pick up the new error TOO_MANY_METASTRINGS and drop a path element and retry, if they expect to be fed old keys. > And I want that you develop a complete > concept (maybe breaking compatability) and that you say: starting on > xx/yy its like this. > > Now you implement something of this and something of that, without a > clear concept. Complete concept is above. The problem is I don't really want to break compatibility instantly. > > E.g. > >At the moment, a key with a superfluous filename will be requested > >successfully. > Ah. Ok. And later this wont work? How should I implement my client > application? What will you say tomorrow? Later on it won't work. The node will return an error indicating too many path components. Specifically, it will return error 11, TOO_MANY_PATH_COMPONENTS (was HAS_MORE_METASTRINGS in older source), described now as "Too many path components" in the short form. The node will include the URI with the superfluous path components chopped off in the error message. The caller is expected to try the new URI, and if it works, to update its copy of the URI to point to the new URI (just like with an HTTP Permanent Redirect; just like with USKs). > > What I meant is that the most compatible way (for client applications) > would be to indicate the "format" of a CHK key (request with/without > filename) in the CHK key itself, but not in its extension. In the long term, all clients will simply request the key as-is. A compatibility kludge which can be implemented in clients is to support the above redirection mechanism. > The AAEC--8 > (OR WHATEVER) was just an idea, because I don't not if this is even > possible. > If it is not possible then just write that it is not possible to > change the CHK key format to indicate what we want. It would be possible to indicate it in the URI, however I am not sure why you would want to. Adding bogus filenames is deprecated. And any such mechanism would be fairly dubious complexity, as there may be more than one level of extra filenames. > > With your current "design" I don't really know how to implement a > working solution into Frost. Currently the only solution seems to > request the CHK with and without a filename, one after the other, > until the download is successful... Request the CHK with the filename. If the node returns an error indicating a new URI, update the CHK to point to that URI, and try again. > > On 10/31/06, toad <toad at amphibian.dyndns.org> wrote: > >On Tue, Oct 31, 2006 at 10:33:58PM +0100, bbackde at googlemail.com wrote: > >> On 10/31/06, toad <toad at amphibian.dyndns.org> wrote: > >> >On Tue, Oct 31, 2006 at 09:34:23PM +0100, bbackde at googlemail.com wrote: > >> >> Why do you add this level of complication? Why could'nt a key with > >> >> filename just be recognizable, e.g. if you change the tralining part > >> >> "AAEC--8" into something different? > >> >> If it breaks compatability now this is no problem because its breaken > >> >> already... > >> > > >> >At the moment, a key with a superfluous filename will be requested > >> >successfully. > >> > > >> >The problem is that at the moment freenet URIs don't behave like normal > >> >URIs. You can add an arbitrary number of extra path elements (slash > >> >followed by string not including slash), and it still work. Which means > >> >we can't compare them. > >> >> > >> >> Some way to add an indication to the keys text representation would be > >> >> very helpful. > >> > > >> >Perhaps. What would you suggest? > >> > > >> >CHK at blah,blah,blah,filename.ext > >> >CHK at blah,blah,blah?filename=filename.ext > >> > >> I vote for a clear solution that indicates the different key types > >> (with/without filename) in the chk key itself, instead of adding > >> another incompatible new extension. > >> > >> As I said the (currently) fix extension AAEC--8 seems to be a good > >> choice for me, why not simply make it AAEC--9 or whatever for keys > >> WITH filenames? This allows applications to clearly differentiate the > >> different key types and how to handle them. > > > >Because AAEC--9 actually means something? It specifies the cipher type > >and so on. > > > >I'm not sure what exactly you want here. > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.5 (GNU/Linux) > > > >iD8DBQFFR8RHA9rUluQ9pFARArA5AJ4o8h7iBlPMSSrtCIy7xIG4I+1ClACgnVI1 > >GO+LjX6IqH9SDtOyKz0lQ1Q= > >=37DW > >-----END PGP SIGNATURE----- > > > > > >_______________________________________________ > >Tech mailing list > >Tech at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -------------- 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/20061101/f69685ed/attachment.pgp>
