Where should it be documented? On the wiki? A page for freenet URIs on the wiki?
On Wed, Nov 01, 2006 at 07:32:23PM +0100, bbackde at googlemail.com wrote: > >Would it help if I implemented the change immediately? > > This would help alot, implement it and document it in very deep detail :) > > E.g. questions like: what if the client provides an encoded key (%xx), > is it decoded before used in the CHK manifest or not? Must the client > decode it? > > And maybe more, I will check if all is clarified once I read your > documentation about this all. Currently there is not alot of > documentation about CHK with filenames vs. CHK without filenames. > > On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > >Would it help if I implemented the change immediately? > > > >On Wed, Nov 01, 2006 at 06:14:58PM +0000, toad wrote: > >> 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 > >> > > > > > > > > >> _______________________________________________ > >> Tech mailing list > >> Tech at freenetproject.org > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.5 (GNU/Linux) > > > >iD8DBQFFSOSdA9rUluQ9pFARAnOWAJ9aP2vdoaak5X7FqC6Nh6pZeM83+wCgnk5t > >GxtmqSUlGdS6Gk4HpCKTXvg= > >=2MZL > >-----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/e3e322c4/attachment.pgp>
