[gmpi] Re: using another plugin API
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 24 Apr 2003 11:19:02 +0200
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, April 24, 2003 9:23 AM
Subject: [gmpi] Re: using another plugin API
> > i thought that the goal was for everybody to bring their own knowledge
and
> > experience on existing SDK (official or unofficial : some of us might
have
> > developped private plug-in API ) in order to design the perfect GMPI.
not to
> > select and custom an existing SDK...
>
> While I want to agree, two things jump out at me:
>
> 1) No one will get their perfect API. I am sure people won't like exactly
> the same things as me, and we'll ALL have to make concessions on design,
> naming, etc.
hum, it depends on this concession rate. I do compromise all the entire
year, why should i have to do the same for free with GMPI.
> 2) The pace of this discussion makes glacier-racing seem like living on
the
> edge. We've not had a new topic for weeks. Each topic takes weeks, and
we
> have about a hundred to go, yet. That is BEFORE we write code.
yes, i've already said some words about that :-). that's sure that i would
prefer that we program something , for example the processing function for a
first step and i'm sure that all the rest will come obviously ...
> I've tried to keep interest in XAP up, but no one seems to care on LAD
> anymore. Maybe I'll spawn my own XAP list. We can finish XAP and then
> propose it as a GMPI starting point. I think XAP already has some GREAT
> ideas in it.
everybody has great idea, the problem is to share all these great ideas to
make a great common GMPI. Not to know how the XAP or whatever SDK are far
from what we could expect. (because someone in this groups should know it !
in fact, this people group should know everything about all plug-in
architecture in the world, that's why the GMPI makes sens)
> Ron, I'm not saying I want to fork the effort, but this pace is not going
to
> get us anywhere, ever.
>
> Tim
>
> p.s. I think AU is ok, but is ugly. I'd want to tear it up and put it
back
> together differently before I called it perfect. But if it were the
defacto
> Open Standard, I'd probably go ahead and use it.
why not ? but what will be the interest of the GMPI group in this case ?
Selecting an existing SDK means to be bound (technically speaking at least)
by the company who built it. Limited by the compatibility... Means that you
depends on a third part company, Means that the GMPI has no power to decide
whatever they need or they would like.
i'm sorry again , but customizing existing SDK is that I do all the entire
year, and everybody can do that without GMPI group ...
all this discussion is a non -sens , sorry , if you find the GMPI group is
not enough productive (and i 'm agree about that) why don't we talk about
new way of work , new method to produce faster !? this debat could make more
sens than to say "yes , we could start with the Winamp SDK and customize
it... :-)",
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:
