29 Nov
2007
29 Nov
'07
12:30 a.m.
Dan Mills <dmills(a)exponent.myzen.co.uk> writes:
Now here is the trick, we convert that to a unique
identifier at run
time by registering each unique event URI as a string in some data
structure (Map, linked list of parameters, whatever), then at event
creation time we set the pointer to point to our single common instance
of the URI. Now all events of a given type have the same value stored in
that pointer which will serve as a unique ID for this event for run of
the programme. If saving event data to disk, we just replace the pointer
with the string it pointed to.
struct event_t {
char * uri;
size_t data_length;
char data[1]
};
On loading a set of events build a list of every unique uri and patch
each events uri pointer to point to it.
I somewhat like the idea, but how would this work for a host dispatching
opaque/unknown events? Maybe such host would load plugin event type uris
From RDF and just use them in opaque way. However, I dont see benefits
over the uri-map approach proposed in the other subthread. using uri map
indexes looks quite more cleaner and intuitive to me than assuming uri
pointers are constant. IMHO later can be quite confisung for not that
experienced plugin writters.
struct known_events {
char *uri;
int (*handler)(struct event_t * ev, void *param);
struct known_events *next;
}
I don't get why this handler callback is needed at all. In LV2 such
events are supposed to be processed during run().
It is worth to discuss how host dispatching opaque events will notify
already instantiated plugins about new event type introduced by loading
new plugin.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>