Separate Plugins from the "framework"

[wzr1337]

To allow independent development of the "framework" and the plugins, spararation is needed.

First propsal:

• rename viwiServer to rsiServer
• separate each plugin into its own REPO prefixed with rsp for RSI Server Plugin
  e.g. rsp-media, rsp-medilibrary
• add rsp-* links to the readme
  describe how to install $npm install rsp-media

alternative to npm: write a small rsp-downloader script that searches github for rsp-* and let the developer choose viw cli which to pull in, so that also all the .git is cloned => better for development?

I need some comments!

Thanks!

[floki-92]

Even tho the viwi.server does not urgently need a tool to manage rsp's there are a lot of reasons to use a unified module...

A rsp-mananger module could have the following features:

• ensuring the existence and the state of rsp's (via git clone and git pull)
• create symbolic links for each rsp (like npm link) so that every application that requires the rsp-mananger can
  • check if the system already has the desired rsp
  • check if the rsp is up-to-date
  • define primary and alternative uris for the repository location of a rsp
• maybe do other things like manage semver functionallity to maintain the version

Advantages:

• rsp-repositories are managed by a unified module that is required in other applications
  • the rsi.server/viwi.server and a lot of other tools could use it to download and rsp's and keep them up-to-date
  • if all rsi tools require the rsp-manager module all the rsp's will exist only once by default. This will just ease development of rsp's.
• locally existing rsps can be easily listed
• the redundant rsp management logic could be removed from all the different applications that automatically pull rsps from somewhere
• the problem that npm does not pull git metadata is solved

[wzr1337]

Sounds good, but adds a few more workpackages ;)

Thanks for your opinion

[BenjaminDobler]

I would extend the cli approach for this and make it similiar to tools like cordova.
There you can say:
rsiServer plugin add pluginId

pluginId could be a npm id or a github repo. The cli would need to deal with those different sources.
Maybe then we could also have a
rsiServer plugin link "local filesystem path"
Which would help with plugin development. Fo this to work the part where the plugins are read would need to be extended to respect those linked paths.

Again similiar to cordova those added plugins would be written to some kind of config file so you never
need to checkin the plugins but the cli could just restore them on each system.

[floki-92]

Agreed, it's a good practice to use the cordova plugin syntax style and a config file.

I still think its better to create a module on github and use it in tools like rsi.server and the cli approach.
Otherwise, a RPM (RSI plugin/packet manager) module would be closed source, since the cli approach is private...

[BenjaminDobler]

I think this is nailed now or?

[wzr1337]

Yep, Closable 😜

On Sun 18. Feb 2018 at 22:42 Benjamin Dobler ***@***.***> wrote: I think this is nailed now or? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADiF7XAj1OhDJ9E-r_80ZdbR9aBM7CRxks5tWJk4gaJpZM4N7TTC> .

-- - Patrick (Mobile)

[wzr1337]

we should discuss wether we want the plugin(s) to be scoped

@rsi-plugin (Singular form)

or

@rsi-plugins (Plural form)

I vote for @rsi-plugin, after a disussion with @fibric

[ghost]

+1 @rsi-plugin

[BenjaminDobler]

We just had a similar discussion here. The question was if it would not make more sense to have everything under the @rsi/ scope and differentiate the plugins by name. So for example:
@rsi/plugin.media

[wzr1337]

@rsi/plugin.media you say?

…

On Mon, Feb 19, 2018 at 12:58 PM, Benjamin Dobler ***@***.***> wrote: We just had a similar discussion here. The question was if it would not make more sense to have everything under the @rsi/ scope and differentiate the plugins by name. So for example: .media — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADiF7ay3vPl67T74APLVCqgdJZpiUSceks5tWWHPgaJpZM4N7TTC> .

-- - Dr. Patrick Bartsch (web)

[BenjaminDobler]

Yes indeed

[wzr1337]

Ok, let's do it this way... WE might need a differnt scope, @rsi seems to be already taken on npmjs.org Any ideas?

On Mon 19. Feb 2018 at 13:40 Benjamin Dobler ***@***.***> wrote: Yes indeed — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADiF7Ro5BXS99CICN5lF7Yi4HgILNZP0ks5tWWvZgaJpZM4N7TTC> .

-- - Patrick (Mobile)

[wzr1337]

done