Re: [Gzz] storm-uri-application.txt

[Benja Fallenstein]

address@hidden wrote:
> Quoting Tuomas Lukka <address@hidden>:
>
>
> > On Thu, Jan 23, 2003 at 10:48:32PM +0100, Benja Fallenstein wrote:
> >
> > > Tuomas Lukka wrote:
> > >
> > > > On Thu, Jan 23, 2003 at 09:26:41PM +0100, Benja Fallenstein wrote:
> > > >
> > > >
> > > > > All,
> > > > >
> > > > > If you haven't looked through 
> > > > > Documentation/misc/storm-urn-application.txt, please do so now. I plan 
> > > > > to submit it tomorrow (Friday).
> > > >
> > > >
> > > > I'm really not sure if we *really* want to put the 00 and 01 ones in
> >
> > there,
> >
> > > > as they are old development versions.
> > >
> > > That would violate the persistency commitment.
> >
> > .. which we haven't made yet, and will make at this point. Because of that,
> > I'd like to keep the least baggage.
>
>
>
> And of course, as stated in the text, if *really* needed, "...future versions of
> this registration may introduce additional identifier variants", which may
> provide e.g. backward compatibility ;). 
>
> At this point, as Tuomas said, we should keep things simple.

This is not keeping things simple, this is insanity. Storm is supposed 
to provide a guarantee about backwards compatibility-- potentially for 
decades or even centuries. Any choices we make now will seem horrible by 
then! If we are not able to provide compatibility for even two years, we 
should simply stop development of Storm right now.

There are a number of design decisions in Storm which I would do 
differently if I could. For example, I would not use MIME messages; I 
would use hashes of the bodies and give content types for them. All the 
headers add currently could be archieved through other means, and this 
would unify namespaces. But we have to provide backward compatibility, 
so we should go for the least disruptive change in order to gather the 
least garbage. I would use base32 instead of base16, as base32 is the 
emerging standard in the p2p community. But we should take the route 
that collects the least garbage while providing backward compatibility. 
And so on.

Tuomas has asserted before that we'd keep the persistency commitment 
(e.g. when switching from 00 to 01 ids, where we didn't break 
compatibility). Now he's willing to break it, after only about a year!, 
because it's inelegant. Now, our current registration doesn't state the 
persistency commitment itself either. If we ever write an RFC which 
includes it, we *will* have collected more garbage along the way, and so 
he'll come again and say, "Well, so far we haven't really made the 
commitment. Let's just drop the data we have so far." How could anybody 
trust their data to a system when its developers speak about long-time 
storage and aren't even able to provide backward compatibility for two 
years?

- Benja