Re: Implementation of music streams

[Erik Sandberg]

On 5/15/06, Han-Wen Nienhuys <address@hidden> wrote:
> Erik Sandberg schreef:
> > However, I have found one good alternative, where the stream event has
> > no unique field. This approach involves a dummy event
> > "AnnounceContext", which are sent by newly created contexts. These
> > messages have no musical meaning, and should not be part of any output
> > file, but you must listen to them if you want to find out about the
> > context structure.
> >
> > I'd suggest that an AnnounceContext event contains a direct reference
> > to the newly created context, as well as a direct reference to the
> > CreateContext event. This makes it very clear which CreateContext
> > events that result in which contexts.
> >
> > I like my new design better than my original one, because data is
> > separated in a more logical way, and because I think it eliminates a
> > bad hack in create_context.
>
> It sounds better, but I'm still not following you completely. Why can't
> you connect the StreamEvents to the appropriate context in the stream
> reader? Ie. why does it need the intervention of (dummy) events?

The main problem is in the stream writer: Even if you hear a
CreateContext event from a context, you don't have a clue how to find
the newly created context (except that you can look at the parent's
children and find the best match, which isn't robust without a unique
value).

There is a similar problem in the reader: When the reader sends a
CreateContext event, it only knows that the event will trigger a
context creation; I don't see a nice way of finding the newly created
context without adding a dummy event.

Erik