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