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 -------------- 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/8a608d83/attachment.pgp>
