A Plugin Plugin !!?

[bengalih]

So I recently got back to messing around with my pretty stable EG setup after I had to get a Roku to replace the deprecated netflix in WMC.

Over the past week or so I have learned quite a bit more about EG than i previously knew. I have learned some python and have offered suggestions to some existing plugins and even coded my own (well, cannibalized an existing plugin to do what I wanted it to ).

One thing that I have noticed over the past couple of weeks is that there are so many plugins that I didn't even know existed. Some of these I think may not even be listed on this forum, but on people's blogs/personal web pages/etc.
Even the ones listed in this forum are hard to find as they are scattered throughout.

I suppose there is some logic as to why only certain plugins are included with EG. My guess would be some level of stability not just for the plugin itself, but also to verify it works well with others?
Perhaps we don't want to include ALL plugins, even if they work flawlessly so as to not confuse the user? Or maybe only plugins that have some commitment to further development?
I'm not sure of the reason, but I think it would be beneficial for people to at least *know* about all the plugins that exist out there.

At first I thought maybe I would compile a list that we could add to that lists each plugin, it's purpose, and links to its pages, etc.
I'm not sure a forum post is the best place for this because then only *I* could edit it, and would have to monitor the thread for changes and update a main thread.
So, I wanted to find out if the community and owners of the project had a better idea?

On thinking of this more I thought to myself....once we have a place where we can store plugin information in a standardized format, why couldn't we write a plugin that connected to this source, enumerated all plugins, and provided the ability to download right into EG? Basically a repository accessible from within the app itself!

This would be a two part project:
1) Define the format for storing the plugin lists.
2) Create the plugin to leverage this list.

Once #1 is complete, work on #2 can begin while we continue to flesh out the data in the list.

I'm not at a python level yet where I feel I could design the plugin from scratch, but I feel I can help facilitate #1 and also work out kinks and polish a rough plugin from #2.

Is there any interest in either of these projects?

[krambriw]

There is definitely a need to organize plugins better. I think the reason why it looks like this is historical. Having them like this in a forum part has maybe one advantage, the most popular and most discussed are shown at the top. The disadvantage is as you say, many good ones will vanish from the front desk and will be hard to find, also it require members to have discipline to put them into the right forum part (this one).

I personally would prefer to have no plugins at all included in the setup. In my opinion it would be better to let the user decide and install plugins separately. One good example how this has been organized is Node-RED. In the basic distribution/setup they have included some basic plugins (called Nodes) belonging to the core and needed to make the thing run. The rest is available downloadable/installable via NPM. This works really nice. I'm not sure how such a thing should be possible to accomplish for EG.

[Sem;colon]

I agree that some central place with all the plugins would be nice.

Something like this has been started on the EG wiki page: http://www.eventghost.org/mediawiki/ind ... le=Plugins
And in the EG documentation: http://www.eventghost.org/docs/pluginlist.html
But both lists are outdated and I didn't find a way to edit the information...

The Wiki page is a very nice Idea and probably the easiest solution - if it would be possible for plugin developers to edit it.. Also a direct link to the plugin list should be on the EG Main Page.

A repository that covers all plugins could be difficult as some plugins are commercial...

I personally would prefer to have no plugins at all included in the setup. ... In the basic distribution/setup they have included some basic plugins (called Nodes) belonging to the core and needed to make the thing run. The rest is available downloadable/installable via NPM. This works really nice. I'm not sure how such a thing should be possible to accomplish for EG.

Some plugins in EG are marked as "core" plugins - I guess that's similar to the nodes - those should stay in the EventGhost setup.
I agree that the rest can be left out, and as far as I know that has already been considered - that's also why no "new" plugins have been included in the setup for years!

[bengalih]

I'm not sure including no plugins is a good alternative...especially for beginning users.
Of course, if during the install there was an option to select to install the core plugins (default) or leave them out, that would be ok.
I think after a basic install a user should be able to begin using the product without resorting to combing through archival forum posts.

None of the existing links of plugin inventories are any where close to being adequate. Additionally, I'm not sure that ONLY the plugin dev should be the one to make people aware of a plugins existence.
Plugins get posted here and there are often no responses for a year or more. That doesn't mean no one is using it, nor does it mean that it shouldn't be able to be easily found and used by a user even though the dev has moved on from it.

I definitely agree that there should be some level of "core" plugin that is guaranteed to work and that the rest could be marked "as-is." But I think a distinction should be drawn between the community/app giving easy access to a plugin repo vs actually supporting those plugins.

I think the wiki page is a good start...really we need a list that is: Plugin name, description, location to download, location for support (if one exists).
I wouldn't mind compiling these in a forum thread, but I really don't want to do the work only to have it fall to the wayside. Also, as I said - only one person can really edit a sticky post.
Would be nice to have a public wiki, but I don't want to start anything that doesn't have the support of the devs.

I find it very difficult to disagree with my sentiment that this sort of updated list of all available plugins is a bad thing to have. If there is disagreement, please voice the reason.

Once that list is compiled, it is a trivial effort to parse it into any syntax, including maybe an XML that a plugin can read and then download the plugin folder to the eventghost location (if someone want to design that).

[kgschlosser]

I can go about coding a plugin that will allow the loading of a list of available plugins (that list will be derived from a repository of sorts). I am thinking that using googles code page would be a good resource for building such a repository. I feel that a moderated repository is a necessity because of the nature of EventGhost and the ability one would have to implement malicious code into EventGhost. As much as i love the "honor" system unfortunately there are people in this world who love to do things of that nature. Or I could make the plugin pull from my server as I have a 280 mbit downstream and a 25 mbit upstream connection which I feel would be more than adequate for the needs of sending the plugin code.

what I am not familiar with is how to send the file other than using telnet with asynchat which would work very easily. I could set up the repository to allow for username password creation that way the original maker of the plugin could make a username and password for his/her self and have the ability to update the code for that plugin right from inside EventGhost. and the plugin would download the code. create the directory and file for that plugin and once the plugin is downloaded the user would be prompted to reboot EventGhost.


this will be no small undertaking for me as i am newish to python but I am pretty sure that if i get a good burst of motivation and people make suggestions and post ideas/coding help I could get this done in a matter of 2-3 days.

Let me know.

K

[krambriw]

For me having developed some plugins, it is important to have a simple solution for distribution. Today I have one place where I store released plugins and a link to all of them in my signature footer. Users interested can easily download and use them if they are interested. So a new solution must be convenient for plugin developers as well.

[kgschlosser]

Hence the Username and Password for having to ability to upload new plugins as well as the ability for the dev of that plugin to be able to upload the newest code.

K

[bengalih]

I think that a 2-3 timeline is aggressive and there is no need to push yourself to those ends. We've gone this long without one, I would prefer that we all come up with a plan that meets all the best criteria.
By that point, others might chime in and add to assist.

Re: using google code pages (which I'm not too familiar with). The problem with the plugins are they are very scattered. I have found certain ones scattered on personal pages (like krambriw states) that are not necessarily also posted here. Those plugin authors might not even use EG anymore, let alone frequent these pages or think about maintaining a plugin or even posting something to code.

For this repo idea to work, I think that it needs to be able to be kept up-to-date very easily, by anyone willing to make the (combined) effort.
I was initially thinking of some type of XML file that could be stored in a central location (here or on google pages) and the format of that XML could just have whatever current location the plugin was located...whether here or on a private page.
We could request that all devs upload their plugins to google code (I'm unsure about the licensing of us doing that for any plugin we find), but I think the code should be flexible to download from any old http location (i.e. you don't need to be signed into this forum to download.).

Ideally all the plugins would be in a central location in the same format, so that they could be downloaded directly into the plugin folder and work, but we might need to build in the flexibility there.

Perhaps a good first draft would be to decide on the input source (xml, etc) and start compiling the plugins? Then, the first version of the plugin could simply enumerate the XML and provide the URL to the plugin location/thread for easy search and (somewhat) easy download by just facilitating the user to get to the right page?

[kgschlosser]

i got ya. what i as saying was 2-3 days to code a built in downloader
K

[Sem;colon]

I agree with krambriw, the solution has to be VERY simple to use, otherwise most of the plugin developers will not use it.

An additional login may already be too much.
Does someone have access to the DB that is used by the forum? Maybe the same accounts can be used?

Please don't get me wrong, I think it is a great idea to build a repository, but it's a lot of work. I'd be happy with a simple list of plugins, with links where they are to find, which the other plugin devs and me can update. This would already be a huge improvement to what we have right now!!

Anyway, if you like to go for the repository, do it. I'd be happy to support, but keep it as open and simple to use as possible.

[SupahNoob]

I'd be happy with a simple list of plugins, with links where they are to find, which the other plugin devs and me can update. This would already be a huge improvement to what we have right now!!

Anyway, if you like to go for the repository, do it. I'd be happy to support, but keep it as open and simple to use as possible.

Honestly, if we had something simple and permanent like this, others could easily build upon it. A plugin to find other plugins is not out of the realm of possibility, but could simply break if we didn't have a rather permanent list of sorts.

[bengalih]

I'd be happy with a simple list of plugins, with links where they are to find, which the other plugin devs and me can update. This would already be a huge improvement to what we have right now!!

Anyway, if you like to go for the repository, do it. I'd be happy to support, but keep it as open and simple to use as possible.

Honestly, if we had something simple and permanent like this, others could easily build upon it. A plugin to find other plugins is not out of the realm of possibility, but could simply break if we didn't have a rather permanent list of sorts.

Hence the OP statement of "...once we have a place where we can store plugin information in a standardized format."

[kgschlosser]

I am just a fly on the wall here, so i listen. and then occasionally fly around and land on someone's cheerios. So whatever is decided. I have more then enough storage space if centralized storage is wanted. my server has been up and running for over 7 years with a 24/7 connection. I just added a 5000VA backup system which should hold the thing up for a pretty good while. or at the very least until i get home and fire up the genny.

there is no cost to this solution in which is why i believe it has not been done before because hosting such a thing requires funds.

this is a free solution.

i really don't like the whole links that are all over the place because of broken links.

and we can set this thing up to mirror the information elsewhere also just in case i get my nighty in a knot or have some kind of a nervous breakdown, or just plain ol croak, or my house burns down (would have larger concerns then EG plugins at that point). the information is still readily available and not lost.

the information is stored on 2 RAID 6 arrays across 16 drives and i have a total of 16 terabytes of storage. all hot swap. only time this thing goes down is for a reboot (never really happens) or for hardware upgrades(just did a large upgrade recently) or replacing the fans (which has ended i believe, i just changed them all to SSO bearing fans)

at the very least making an inventory of what is available and a central place to store would make the list a hell of a lot easier to maintain. with or without passwords for a dev to update their code.

Offer is there.

K

[kgschlosser]

and it would also standardize the means in which to download the plugin. and a list could simply be derived from a file located in the plugin directory with a name and description and author.


all standardized.

[krambriw]

The plugins does not require much space. In fact, I think the space offered for free with a Google Drive (15GB) or even Dropbox (2GB) account is more than enough for all plugins we have and could ever invent. I would prefer a cloud solution in this case. It's anyway kind of you, kgschlosser, to offer hosting.

BR Walter