[gmpi] Re: where we at
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 5 Aug 2003 10:41:08 +0200
----- Original Message -----
From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, August 05, 2003 2:19 AM
Subject: [gmpi] Re: where we at
> > I think it is clear that people are losing interest, and I believe this
is
> > because there is no immediate reward for our thoughts. Possibly, people
> > should propose models of a complete plugin API, several alternative
models
> > that is, and solicit contributions and refinements. Then we could vote,
or
> > something. These models would be in the form of stub host/stub plugin
and
> > enable all negotatios, graph construction, etc.
>
> Hi Michael et all,
> I like Michael's proposal. We spend a lot of effort arguing about
> implementation details, and a lot of time arguing about which of two
> approaches is simpler/more efficient/etc.
> If we had an *absolute* minimum implementation. It would provide a test
> bed for various ideas.
> I don't know how many times I've dreamt up a simple, elegant design,
only
> to have it crash and burn under the harsh reality of actually coding it.
>
> We could get some real performance figures for "baton passing vs
> pre-allocated buffers" for instance.
>
> I suggest it's also a more modern, iterative approach to design. ("Extreme
> Programming" is the label).
> Our current approach is more 'top-down'?, is that the term?. (the word
> "Bloatware" also springs to mind, but perhaps i'm biased).
>
> The downside is the potential chaos of managing the process.
>
> What do you all think?
by experience, i know that a single SDK to make all possible plug-in
variations is a hell... in term of time (so in term of money) in term of
reliability and quality of the final product. General plug-in SDK already
exists, the name is Direct-X. And in Direct-X the first source of problem
met by the programmer is the COM interface itself (many implementations does
not know exactely when ::Release means "free interface" or "free object"
:-))) ...
Trying to build a general plug-in SDK first is even for me a non-sens . When
i build an architecture, i always begin by the minimal version. Designing a
minimal version allows you to see what is already possible and what is
missing. According that, we can after or upgrade the minimal version or
build a new architecture (but the advantage is that the base is here and
every one knows about what we are talking).
so before designing a GMPI i would like we make a MMPI :-) also because
minimal impementation can be done with a minimum of discussion and can be
coded in the meantime. This first base, i'm sure, would help us to rich the
final goal faster, avoid useless discussion, non sens votes, and fake
issues.
Regards
Vincent Burel
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
