Hello, any progress on this item? I wait for a final implementation and documentation. Then I can start to implement this.
On 11/1/06, bbackde at googlemail.com <bbackde at googlemail.com> wrote: > On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > Where should it be documented? On the wiki? A page for freenet URIs on > > the wiki? > > Of course in the wiki. On some new page or a subpage describing the > URI format to use in get,put,... > > > > > 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 > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.5 (GNU/Linux) > > > > iD8DBQFFSO4KA9rUluQ9pFARAlf1AJ9P6LjHQRLg0r4IRfRTJUtwf3msQwCgv1fP > > yTYkvUCrZZGuMTmwkSy3PR4= > > =GBYR > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > >
