> 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 > >
