----- Original Message -----
From: "Brandon" <[email protected]>

> This is way complicated and with no apparent good reason. I'm suggesting a
> much simpler restructuring in which most of the old keys still work
> (everything but MSKs).
>
> Old keys:
> KSK at string
> CHK at dockey,enckey
> SSK at pubkey[,privkey]/string
> MSK at key//[string]
>
> New keys:
> KSK at string[//docname]
> CHK at dockey,enckey[//docname]
> SSK at pubkey[,privkey][,baseline,increment]/string[//docname]
>
> It's actually simpler than before rather than more complicated.
>
> Likewise, with metadata you previously had Redirect and DateBasedRedirect
> and you now only have Redirect. So metadata has been simplified as well.
>
> I see no reason to complicate things at this point when a simpler system
> does everything that we need.

Becuase our needs will change. I really doubt that we won't come up with
some new cool thing we can do to SSKs. Overloading the SSK syntax is quite
frankly a nieve thing to do in the long run. Later we'll end up sticking
another field item in there, and how do you tell the difference between
SSK at pubkey,privkey/string and SSK at pubkey,newfield/string ?

The easy way is that you don't set a precedent of throwing everything into
the SSK fields and instead come up with a system that will allow the
different handlers to change.

AGLs way means that we can change to those new methods with the minimum of
hassle later (although I'm not sure about the syntax personally :p)

-Mathew


_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl

Reply via email to