On Saturday 13 February 2010 02:50:13 Martin 'The Bishop' Scheffler wrote: > On Saturday 13 February 2010 00:39:02 Matthew Toseland wrote: > > On Friday 12 February 2010 13:46:42 Evan Daniel wrote: > > > Ideally, that's true. In practice, the blame gets assigned to the > > > people who made the change that broke it, not the people who ignored > > > the spec or failed to update their software. At least, that's my > > > experience... > > > > Agreed. IMHO it would be inappropriate to make it easy for third party > > plugin authors to create bogus metadata. If you *really* want to be able > > to create stuff with arbitrary metadata you can use binary blobs. > > NAK. > What can be done (by patching fred), will be done - there is really no point > in restricting raw access to java hackers. > My request is just to expose a raw key interface at the FCPv2-level. > Sane users will still use fproxy or the standard FCP functions.
If you are going to build your own metadata formats, why not just insert stuff as data, not metadata? If you are going to fetch existing data inserted using our standard metadata formats, we lose the ability to change them as soon as your tool becomes popular. We had this sort of chaos through 0.5, it was not a good thing. If you want new features hack them in in Java. It's really not a hard language to learn, especially if you know C++ or similar. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100213/c0fbeeb3/attachment.pgp>
