Proposal for new plugin system

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for new plugin system

Robin Appelman
Because our current plugin system isn't powerful enough for some cases, I've
written a proposal on the wiki for a new system that would be more dynamic and
allow for easier installation of plugins.

http://owncloud.org/index.php/Plugin_System_Proposal

 - Robin Appelman

Reply | Threaded
Open this post in threaded view
|

Proposal for new plugin system

Frank Karlitschek
Perfect.

Exactly my idea. :-)

We should also have a way for the plugins to register themselves for the navigation.
Something like OC_NAVI::addentry('musicplayer','plugins/musicplayer/main.php');


Cheers
Frank


On 28.07.2010, at 15:18, Robin wrote:

> Because our current plugin system isn't powerful enough for some cases, I've
> written a proposal on the wiki for a new system that would be more dynamic and
> allow for easier installation of plugins.
>
> http://owncloud.org/index.php/Plugin_System_Proposal
>
> - Robin Appelman
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud


--
Frank Karlitschek
karlitschek at kde.org





Reply | Threaded
Open this post in threaded view
|

Proposal for new plugin system

Aldo "xoen" Giambelluca
In reply to this post by Robin Appelman
2010/7/28 Robin <icewind1991 at gmail.com>:
> Because our current plugin system isn't powerful enough for some cases, I've
> written a proposal on the wiki for a new system that would be more dynamic and
> allow for easier installation of plugins.
> http://owncloud.org/index.php/Plugin_System_Proposal
Interesting :)


PLUGIN.XML
==========
  1. I suggest to change <meta> in <info> or <information>
  2. Add <description> to <meta>
  3. Add <homepage> to <meta>
  4. Add <email> to <meta>
  5. Put all the <include> in something like <runtime>
  6. Add <uninstall> identical to <install> but for uninstallation
  7. It's important to have a version attribute into plugin
    (<plugin version="1.0">), this way it's possible to change the
    plugin.xml structure in future.
  8. Maybe we need a require child in <meta>? Something like
     <require>1.0</require>, some way to know in which versions of
     ownCloud the plugin works.

I will prefer if the filename is fixed so I know every plugin has a
`plugin.xml`.

See attachment for an example.


INSTALLATION
============
I don't like the idea to use the `plugin.xml` file to guaranty the
plugin is installed correctly.

IMHO it would be better to insert the plugin in a DB table after the
(successful) installation, see LOADING.

Of course if the `plugin.xml` version is not complatible the plugin will
not be installed (see PLUGIN.XML point 7).


LOADING
=======
IMHO, it would be better has a `oc_plugins` DB table in which there is
a row for each installed plugins.
Every row contains information on the plugin: id, enabled, name,
version, description, author, e-mail, homepage, licence and copyright.

The enabled field can be false or true, if true the plugin is loaded.
(Of course if the plugin is incompatible with the version of ownCloud
installed will not be loaded, see PLUGIN.XML point 8).



This should be flexible enough (TM), but I'm sure reading this you
will have new ideas ;).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugin.xml
Type: text/xml
Size: 850 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/owncloud/attachments/20100728/72ef5c3f/attachment.xml 

Reply | Threaded
Open this post in threaded view
|

Proposal for new plugin system

Robin Appelman
On Wednesday, July 28, 2010 21:53:08 you wrote:

> 2010/7/28 Robin <icewind1991 at gmail.com>:
> > Because our current plugin system isn't powerful enough for some cases,
> > I've written a proposal on the wiki for a new system that would be more
> > dynamic and allow for easier installation of plugins.
> > http://owncloud.org/index.php/Plugin_System_Proposal
>
> Interesting :)
>
>
> PLUGIN.XML
> ==========
>   1. I suggest to change <meta> in <info> or <information>
>   2. Add <description> to <meta>
>   3. Add <homepage> to <meta>
>   4. Add <email> to <meta>
>   5. Put all the <include> in something like <runtime>
>   6. Add <uninstall> identical to <install> but for uninstallation
>   7. It's important to have a version attribute into plugin
>     (<plugin version="1.0">), this way it's possible to change the
>     plugin.xml structure in future.
>   8. Maybe we need a require child in <meta>? Something like
>      <require>1.0</require>, some way to know in which versions of
>      ownCloud the plugin works.
>
> I will prefer if the filename is fixed so I know every plugin has a
> `plugin.xml`.
>
> See attachment for an example.
Good suggestions, updated the proposal for the plugin.xml structure with these
in mind.

>
>
> INSTALLATION
> ============
> I don't like the idea to use the `plugin.xml` file to guaranty the
> plugin is installed correctly.
>
> IMHO it would be better to insert the plugin in a DB table after the
> (successful) installation, see LOADING.
>
> Of course if the `plugin.xml` version is not complatible the plugin will
> not be installed (see PLUGIN.XML point 7).
>
>
> LOADING
> =======
> IMHO, it would be better has a `oc_plugins` DB table in which there is
> a row for each installed plugins.
> Every row contains information on the plugin: id, enabled, name,
> version, description, author, e-mail, homepage, licence and copyright.
>
> The enabled field can be false or true, if true the plugin is loaded.
> (Of course if the plugin is incompatible with the version of ownCloud
> installed will not be loaded, see PLUGIN.XML point 8).
>
>
> This should be flexible enough (TM), but I'm sure reading this you
> will have new ideas ;).
Not sure about this, saving a list of the plugins in the database seems
unnecessary to me, we need some more discussion on this.

Reply | Threaded
Open this post in threaded view
|

Proposal for new plugin system

Frank Karlitschek

On 28.07.2010, at 22:50, Robin wrote:

> On Wednesday, July 28, 2010 21:53:08 you wrote:
>> 2010/7/28 Robin <icewind1991 at gmail.com>:
>>> Because our current plugin system isn't powerful enough for some cases,
>>> I've written a proposal on the wiki for a new system that would be more
>>> dynamic and allow for easier installation of plugins.
>>> http://owncloud.org/index.php/Plugin_System_Proposal
>>
>> Interesting :)
>>
>>
>> PLUGIN.XML
>> ==========
>>  1. I suggest to change <meta> in <info> or <information>
>>  2. Add <description> to <meta>
>>  3. Add <homepage> to <meta>
>>  4. Add <email> to <meta>
>>  5. Put all the <include> in something like <runtime>
>>  6. Add <uninstall> identical to <install> but for uninstallation
>>  7. It's important to have a version attribute into plugin
>>    (<plugin version="1.0">), this way it's possible to change the
>>    plugin.xml structure in future.
>>  8. Maybe we need a require child in <meta>? Something like
>>     <require>1.0</require>, some way to know in which versions of
>>     ownCloud the plugin works.
>>
>> I will prefer if the filename is fixed so I know every plugin has a
>> `plugin.xml`.
>>
>> See attachment for an example.
> Good suggestions, updated the proposal for the plugin.xml structure with these
> in mind.
>>
>>
>> INSTALLATION
>> ============
>> I don't like the idea to use the `plugin.xml` file to guaranty the
>> plugin is installed correctly.
>>
>> IMHO it would be better to insert the plugin in a DB table after the
>> (successful) installation, see LOADING.
>>
>> Of course if the `plugin.xml` version is not complatible the plugin will
>> not be installed (see PLUGIN.XML point 7).
>>
>>
>> LOADING
>> =======
>> IMHO, it would be better has a `oc_plugins` DB table in which there is
>> a row for each installed plugins.
>> Every row contains information on the plugin: id, enabled, name,
>> version, description, author, e-mail, homepage, licence and copyright.
>>
>> The enabled field can be false or true, if true the plugin is loaded.
>> (Of course if the plugin is incompatible with the version of ownCloud
>> installed will not be loaded, see PLUGIN.XML point 8).
>>
>>
>> This should be flexible enough (TM), but I'm sure reading this you
>> will have new ideas ;).
> Not sure about this, saving a list of the plugins in the database seems
> unnecessary to me, we need some more discussion on this.

I also don?t see the point in mirroring the data in the database.
I think having the data in the xml together with a convenient class to access the data is enough.


Cheers
Frank


--
Frank Karlitschek
karlitschek at kde.org