On Tue, Oct 21, 2003 at 06:59:11PM -0400, Taybin Rutkin wrote:
> I would like GMPI to be ready for future enhancements so that it can
> maintain backwards compatibility. For instance, if a bitfield is used,
> make it a large-ish one for future enhancements without breaking older
> hosts.
You'll h
I would like GMPI to be ready for future enhancements so that it can
maintain backwards compatibility. For instance, if a bitfield is used,
make it a large-ish one for future enhancements without breaking older
hosts.
Taybin
On Tue, Oct 21, 2003 at 11:47:33 -0700, Tim Hockin wrote:
> > It probably should be in the spec, or at least a recommended schema. There
> > better be a good reason for it being anything other than XML.
>
> The *spec* certainly. But requirements? The requirement seems to be "GMPI
> should have a
On Tue, Oct 21, 2003 at 07:50:38PM +0100, Steve Harris wrote:
> > We're not designing solutions, just requirements, right now. It's fine to
> > have a solution to a requirement, but remember that this is a bigger group.
> > I don't even know what YAML is. XML is a somewhat obvious answer for
> >
On Tue, Oct 21, 2003 at 11:20:04 -0700, Tim Hockin wrote:
> > 2) Explicit versioning for API?
>
> Versioning of...?
The API I expect, this is necceasry to allow multli API plugins (LADSPA
want versioned and is now).
A #define is enough.
> > 4) uniq IDs for plugins?
> >who is authority?
>
On Tue, Oct 21, 2003 at 06:43:14PM +0400, "horsh" wrote:
> 1)is API monolithous or there are sub-APIs
> like GMPI-audio, GMPI-seq, GMPI-control
These are requirements. It's not time to decide such things. Hopefully,
it's one main API, with as few as possible support APIs (which are required
so
1)is API monolithous or there are sub-APIs
like GMPI-audio, GMPI-seq, GMPI-control
2) Explicit versioning for API?
3) Explicit versioning for plugins?
4) uniq IDs for plugins?
who is authority?
5) format for plugin state saving:
XML? (damn its ugly!)
I vote for more YAML-like languag
