Voting - plugins not included in the installation file

[Pako]

Should we have a link to the official SVN somewhere on the site? Maybe on the Downloads page?

This is a good idea.
Perhaps there should be something to the effect that the SVN is there and there ...
and that it is the only place where you can always download the latest development versions of plugins.
Very nice it would be if there were to see the serial number of latest revision.
So, could see the difference between the last revision and revision, which is included in the installation file.

Pako

[abraxxa]

The revision is something subversion specific and should not reflect the version of a programm or plugin, because if you change your vcs and the new one has no increasing revision numbers like git which uses sha1's you're versioning would be broken.
Each plugin already has a version number which should indicate exactly what it was added to the plugin at first: the version number.

[Pako]

The revision is something subversion specific and should not reflect the version of a programm or plugin, because if you change your vcs and the new one has no increasing revision numbers like git which uses sha1's you're versioning would be broken.
Each plugin already has a version number which should indicate exactly what it was added to the plugin at first: the version number.

I did not understand (maybe my poor English).
I just know that part of the name of the installation file (build) is always the number that matches the revision number that was last in the creating time of the installation file.
And I also know that with each command commit always automatically increments the revision number.
It follows that the difference between the build-number and the current latest revision of very roughly indicates how far we moved (in the repository) away from the installation file.

Pako

[abraxxa]

Yes, that's a subversion specifc thing and isn't good practice.

[Pako]

I am currently working on the integration of selected plugins to the SVN repository.
But I have a problem.
I can not test all the plugin itself (in some cases even impossible, because I do not have the external device).
I can not even read the entire contents of some topics in the forum.
Therefore I need some advice.
Right now I need to know if the plugin Dynamic Webserver is the full replacement of Webserver plugin,
or whether it is necessary that the installer file contains two plugins.
If just one, that new of course will only appoint a Webserver to ensure backward compatibility.

Thank you for your expertise and opinions!

Pako

[jitterjames]

I am not 100% sure but I think the new webserver does everything the old one does.

I recommend for now that you include both. They are both small right?

[Pako]

I recommend for now that you include both. They are both small right?

Size is not important at all.
I want to setup file not contain useless things, which would also confuse (especially) new users (why two same plugins ?).
If old plugin can be replaced by a new, we'll have to do now.
Imagine this situation:
Step 1: User xxxx add to configuration the Dynamic Webserver plugin
Step 2: We delete the Webserver plugin and the Dynamic Webser plugin we renamed to Webserver
Step 3: User xxxx has a problem: there is no plugin Dynamic Webserver

Pako

[jitterjames]

no matter what you do it will cause problems.

If you replace the old webserver with the new one it will cause problems for existing users of the dynamic webserver. I use the dynamic webserver, but I have both plugins installed. If you rename dynamicwebserver to webserver my configuration will no longer work. That is fine since I know what I am doing and I simply need to change to webserver plugin and reconfigure. But it is a pain.

If you keep both, it may cause confusion for new users, since they will have to decide which one to use, but this is the only way to maintain backwards compatibility for everyone.

For new users as long as the plugins contain descriptions, it is up to them to decide which one they would want to use. It would be nice if the old version could contain the word "deprecated" in the description, and suggest that the user use the dynamic webserver instead. I am happy to edit the original webserver plugin with a new description but I don't have svn access so please tell me where to upload the file.

[Pako]

Yes, I agree, yet we must have both plugins.
It is a great pity that Bitmonster not complete his plan:

Since nearly half a year I observe my decreasing joy to work on this project. There are many reasons for it, but I won't comment on this now. Anyhow, here are just some notes of what will most likely happen in the future from my side:

1. I will implement a kind of "EventGhost Plugin Installer Format", that will help users to install plugins that are not part of the basic installer. It will basically be a ZIP file with a special file extension, so EventGhost can handle the installation if the user opens it through EventGhost and everything can stay bundled in a single file (including DLLs and other stuff).
2. Plugin developers can then upload their plugins to the wiki. This way plugin developers won't need any special privileges to publish/update their plugins and have a basic version control system. The wiki will be extended to extract some informations from the uploaded plugins to generate an index of all plugins available. So users can search for plugins that might be interesting for them.
3. EventGhost possibly then also gets a function to find missing plugins if a configuration XML is opened and download them automatically to complete the setup (for example after a complete new install).
4. Once this is implemented, I will move many plugins out of the basic installer. Including many plugins that are written by me.

This is also the reason why I currently won't give new plugin developers SVN write-access. Most plugins will be removed from the trunk anyway.

I would very like, if we could do it this way.
But I do not have the necessary skills.
We urgently need someone who could continue this development.

For new users as long as the plugins contain descriptions, it is up to them to decide which one they would want to use. It would be nice if the old version could contain the word "deprecated" in the description, and suggest that the user use the dynamic webserver instead. I am happy to edit the original webserver plugin with a new description but I don't have svn access so please tell me where to upload the file.

Please give a modified plugin here as attachment.
I can also give you access to the SVN ...

Pako

[Pako]

I just came to XBMCrepeat plugin.
Although I've read that with this plugin we can replace the old plugin.
But it looks like it's the same situation as the Webserver plugin.
How do I do?

Pako

[jitterjames]

If I am going to edit the dynamic webserver, I want to make sure that I am using the latest version. Is this now available via the sourceforge svn or should I download it from the forum?

I think we should do the same thing with the xbmc-repeat plugin. It would be nice if the developers of these plugins would be a bit more involved in the process!

HINT HINT...

Perhaps we can add some notices to the new "News" forum warning people that certain plugins that are depricated will be removed in the next version and provide a list of plugins that are depricated. We can probably also do a special announcement that will get emailed to all forum members.

In any case, if you are installing a newer version of EG on top of an older version, I don't think that it will delete your existing plugins. So, as long as we don't rename any of the plugins, it is probably ok to remove the old versions. In other words, even if we remove the original webserver plugin the dynamic webserver should continue to be named "dynamic webserver" to avoid confusion.

I would just like to say Pako: I know that you are working hard on this without much help from anyone and I hope I speak for everyone when I say that your effort is greatly appreciated.

It is a thankless task, but thank-you anyway

[abraxxa]

Every plugin author should develop the way he/she prefers, including his/her vcs of choice.
Mine is git and I use github for the OnkyoISCP plugin.
The thread in the forum just links to the repo which has a tag for every version.
I also update the plugin thread so people see that a new version is available.
Having no vcs is bad and plugin developers should be told to do so.

For Eventghost I'd keep its and the bundles version number separated and just include the Eventghost version and say a date as the bundle identifier, e.g. EventGhost-0.3.7-bundle-2011-01.zip.

[jonib]

I just came to XBMCrepeat plugin.
Although I've read that with this plugin we can replace the old plugin.
But it looks like it's the same situation as the Webserver plugin.
How do I do?

As XBMCRepeat can do everything the old XBMC plugin does (and more ), I think it's OK to remove the old plugin.
If somebody uses the old plugin and updates EventGhost the old plugin would still be available.
And new users won't have two plugins to choose from, as there is no advantage to the old plugin.

I think the XBMCRepeat plugin should be put in a XBMC2 directory so it won't overwrite the old plugin for people upgrading.

jonib

[jitterjames]

I agree, but wouldn't it be better to leave it in the XBMCrepeat directory?

[jonib]

I agree, but wouldn't it be better to leave it in the XBMCrepeat directory?

I kinda would like to name it XBMC2 instead as "Repeat" was just to distinguish it from the "official" plugin, and I think a simple name like XBMC2 is better.

jonib