Plugins: 2 standards, what now? (NEVERMIND, ITS DONE)

[Space Fractal]

It seen some of us is now begin to write each your plugin system.

I might pulling out now, since we cant define a standard posted in the other thread.

If all of us begin to create thier own standard, this project will now dead allready. Hence I won't host the webserver and pay for the domain name.

Now I cant see a point about this elsewice awesome project, undtil I hear what plugin writers would want to do and wich commands they want use.

Because of that I stopped impleting this system into MultiJuke, until we have one standard, if we also can agree. I wont use my own standard as well.

I think we should start from beginning? I think I create a wiki page for idea instead of using a thread for that (so all can submit).

[loadman]

Space Fractal :

Thanks for your input. 

But you are right. You and UncleT aren't go to agree it seems.

In my opinion if I where you I would not bother going down the Wiki route as I don't think you are prepared to compromise enough.

You are obviously very 'passionate' and enthusiastic but the complexity level you are bringing (IMHO) is way too much for a plug-in.

Looks like the only way you will be happy is to have your own system or nothing, which is up to you.

So please don't take offence 

It was worth a shot at trying to make a global system.

 

[Space Fractal]

let start from beginning. I pull complety off (I do not start a new thread anymore about it).

I might ask saint to all threads about it, includning the SDK.

____

NB. I have askad saint to either to lock these threads, created by me (just me), and/or move them to hell.

Thanks for the debate, but it seen it goes over the rules.

[loadman]

let start from beginning. I pull complety off (I do not start a new thread anymore about it).

I might ask saint to all threads about it, includning the SDK.

____

NB. I have askad saint to either to lock these threads, created by me (just me), and/or move them to hell.

Thanks for the debate, but it seen it goes over the rules.

I don't know why you are getting so upset?

A shame. 

I can only assume you are missunderstanding me as English is not your first Language?

[Space Fractal]

Sorry if I upset, it was just maybe your humor or such, when we are allready upset.

Again, Sorry.

I think we should try from a new beginning and let plugin writers debate which functions we should use, NOT by the Jukebox Authors.

So I think you should start a new thread with your SDK (because you are a plugin writer).

I trying to fix the issues with the SDK I gave, but I want to hear UncleT how I can change. There might been some problems. SO changed to Unfinished status instead of dropped.

[Barry Barcrest]

Looks like the only way you will be happy is to have your own system or nothing, which is up to you.

Well to be honest you could say this to Uncle T or myself as well, it's not really fair to single Space Fractal out as the only one who gave out this impression.

It was worth a shot at trying to make a global system.

Well from the off it was always going to be you going with whatever Uncle T went for as you guys started this off. As you were the only interested Plugin Author this pretty much dictated the whole project and there wasn't really much chance of us making a global system. The best we can hope for now is that UncleT documents his system sufficiently that others like myself can offer support for that system.

[Space Fractal]

I have not impletered any system in my software, before I have seen UncleT post about the reedited SDK.

Thanks for the post, Barcrest.

Even I have my own software i did have actually plans to make a plug-in or two... to suit all software, not just mine. I also want to make mine plugins compatible with all software, even I have my own software.

Instead It seen might add these functions as unique features to MultiJuke without adding a plugin system.

My SDK was really to tried to fit a least UncleT Jukebox, Freebox, DWJukebox (if Chris was interested)  and of course my own software in mind. Instead UncleT did go another way instead of comments what I could change and what I could change.

Now I have edited the SDK, cleaned up, to fit some compromise from both me and UncleT....

[unclet]

I have many times indicated that I was not willing to use a commands.txt file and did not want to interface with a 3rd party wrapper which maintains all the plugins for me and redirects commands to each plugin for me.    Apart from these two objections I think I have been willing to listen to any proposal, but each time an update was provided it always included the commands.txt file and 3rd party wrapper.

Now, in the other thread ..... I am really trying to understand why Space Fractal wants to use a "commands.txt" file and why he requires a "wrapper" function at all?  Once I fully understand why Space Fractal really wants to use these items then I might have a better idea on what type of design and functionality Space Fractal desired.    However, right now, I do not understand why "commands.txt" or "wrapper" is required.

PS:  I know Space Fractal indicated the "commands.txt" file is gone .... but the main reason behind the "commands.txt" file existing in the first place still exists ........ Space Fractal still wants the plugin to "remember" which commands can be sent from the jukebox software for some reason and I am really interested in trying to determine exactly why this is the case.  Once I have that answer then hopefully this ball will get rolling in the right direction again ....... and a jukebox plugin system (jps) wont be too far behind.

[headkaze]

PS:  I know Space Fractal indicated the "commands.txt" file is gone .... but the main reason behind the "commands.txt" file existing in the first place still exists ........ Space Fractal still wants the plugin to "remember" which commands can be sent from the jukebox software for some reason and I am really interested in trying to determine exactly why this is the case.  Once I have that answer then hopefully this ball will get rolling in the right direction again ....... and a jukebox plugin system (jps) wont be too far behind.

I have to agree with you on this point unclet. No matter how much I try to understand why Space Fractal wants commands.txt I just can't see the point to it. I still don't.

The alternative (and better) solution to commands.txt is (1) Documentation including (A) The Plugin SDK (which includes a list of common commands) and (B) The Jukebox software docs (which will list commands that are unique to that program) and (2) Plugin Version numbers (which indicate which commands are supported in a particular version of Plugin format). Plugins should be "backward compatible" so if your Juke software supports JPS v2.0 then it should also support JPS v1.0.

And as I have repeated numerous time (ad nauseum) the Plugin coder adds support for the commands they want to support. The Jukebox coder doesn't need to tell the Plugin coder which commands they use and should be supporting, he will read the documentation and support the commands he/she wants in the Jukebox software of their choice.

If you understand the reason a Plugin coder writes a plugin it is usually to extend the software he/she uses for their own purpose. They share the plugin so others can use it but their purpose for writing it is to enhance the functionality of the program (like Loadman wants to do with unclet's Jukebox software). They don't care if it works in other software (in most cases) so the plugin should just work if it's copied into another Jukebox plugin folder. He should not have to worry about different commands in different Juke software INCLUDING some annoying commands.txt file that will differ between software.

[Space Fractal]

I and UncleT did go progress now. It look like we have a final SDK ready soon  .

I gave a config example screenshots why I could use these commands....

[loadman]

Looks like the only way you will be happy is to have your own system or nothing, which is up to you.

Well to be honest you could say this to Uncle T or myself as well, it's not really fair to single Space Fractal out as the only one who gave out this impression.

Fair Enough Sorry.

It was worth a shot at trying to make a global system.

Well from the off it was always going to be you going with whatever Uncle T went for as you guys started this off. As you were the only interested Plugin Author this pretty much dictated the whole project and there wasn't really much chance of us making a global system. The best we can hope for now is that UncleT documents his system sufficiently that others like myself can offer support for that system.

My feelings are in the other post, but yeah I never denied this. My original post was in the UncleT section and he had it moved here as he and I thought it was worth a shot trying to make a global system.

The Jukebox coder doesn't need to tell the Plugin coder which commands they use and should be supporting, he will read the documentation and support the commands he/she wants in the Jukebox software of their choice.

 

I and UncleT did go progress now. It look like we have a final SDK ready soon  .
I gave a config example screenshots why I could use these commands....

[Space Fractal]

I should never posted this thread, that I was very upset. I was propeply tired (was very late danish time).

Now I and UncleT is back to the track and he going to understand why I did use that functions defined in the SDK (big thanks to HeadKaze for his screenshots).

There are still isues left, now it about the "VB6 Pitfall" when sending back to jukebox application. But it a good debate now.

So, I hope the SDK is finished throuch few days with examples to avoid the "VB6 pitfall". when its done I PM to all authors (and these 2 known plugin writers).