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

[Benja Fallenstein]

Tuomas Lukka wrote:
> On Fri, Jan 24, 2003 at 02:26:13PM +0100, Benja Fallenstein wrote:
> > So you are intending to throw 
> > away my data?
>
>
> Ok, if you have real data, then that changes things. No problem then.

Hm. Let's see. I do, but not very much; while converting a set of Storm 
blocks is a nightmare, as you have to update the references to other 
blocks (as experienced by Rauli), it would be possible to write a dumper 
to A-J's spacedump format, losing the xu data, and I'd be prepared to go 
with that.

Then there is the shared data from the time before last spring's 
rewrite. I remember that Tero spent a lot of time on getting some Clasm 
things to work. Any others with data in that space they do not want to 
lose? (I don't have any.) We should also be able to convert this data 
while losing xu connectivity.

I do not know about the pp project, but since nobody mentioned it, I 
guess there isn't any data there that needs to be preserved?

If we have a dumper for the current format (and I do think I can write 
one), there is still the issue of principle. As antont said on IRC:

<antont> benja: i wonder about the backwards compatibility: from teh 
arguments i've seen from You and Tuomas, there seems to be a difference:
+for you it's a matter of principle (a one that everyone agrees on, i 
suppose) - but Tuomas indicated only practical reas
<antont> ons (i.e. your existing real data) in his post.

So far, I thought that there was an agreement that we would not drop 
compatibility for Storm blocks (because it's so horribly hard to convert 
them to another format). As I said in another mail, how can you trust 
Storm if one day we say we won't break backwards compat, and the next 
day we do?

Then again, this *is* a development version. I can see how it may be 
justified to break compat here if we can make the system simpler for it.

However, I think that just like in a full-fledged, widely used 
implementation, the Persistency Commitment *does* apply to the 
development versions: "Future versions of this specification will allow 
data to be read that can be read according to this version of the 
specification." There is only one way to do something not backwards 
compatible: Write a different specification (not an update to the other 
one).

We can do that. In my opinion, then, we should address all the issues 
there are with Storm, currently, doing a clean-slate design based on 
what we have learned. The 02 identifier design is *very much* influenced 
by the need to provide backwards compatibility. I would like to correct 
a great many design choices if we aren't bound to that.

I also believe very much that this needs a PEG. Breaking backwards 
compat as a side-thought of a URN registration seems VERY BAD to me.

And then there's the issue that this is a very bad time, as we're 
currently writing the Storm article.

I'm willing to provide ideas about a non-backward-compat, Storm-like 
system if there is interest. But I do want this to go through the PEG 
process, and I do want there to be a zzstructure-level converter tool. 
And I do want the honesty of acknowledging that this is a *new* system, 
throwing the development system away because of what we've learned in 
the process. *And* I want a clear statement about the persistency 
commitment we give (maybe: this specification is committed to it, but 
until 0.8beta we may switch to yet another system if there is need).

Agree?

- Benja (whew)