Plugins should have access to resources of other plugins

[BenjaminDobler]

I`m thinking of situations where you have a resource that contains elements which contain references to elements of other resources. How would a plugin right now get information about these resources (e.g. maybe to expand them or update them).
Maybe each plugin could get registered in some kind of plugin registry and this registry is then exposed to each plugin?

[wzr1337]

good idea.. the plugin loader might expose these information

for now I'd recommend too just "import" the needed parts

[wzr1337]

Within a service, you can now lookup resources by using getResource(name:string).

It is part of a refactoring service class

[codeundkakao]

What is the desired feature scope for this?

Given that resources within a service do actually know and now can also lookup each other this already provides the ability to implement a plugin logic that for instance let's a resource modify certain other resources within the same service based on it's own current data set.

Benjamin's initial thought was going further by suggesting a mechanism to provide each service with information about all available services and thus enable an interaction between services.

Maybe it should be defined in which extend such functionality should be implemented.

[wzr1337]

Ok, This would mean some central service registry for the server side implementation,right? The router is the only component right now that has all information. The plugin loader registers all pluggins at the router and for websocket. Maybe we can extract a singleton component here that gives an interface to register and list without using the external REST API. Viwi supports exploration anyway, but on its external API.. Am thoughts on a smart solution?

On Wed 12. Apr 2017 at 12:14 alexander thieme ***@***.***> wrote: What is the desired feature scope for this? Given that resources within a service do actually know and now can also lookup each other this already gives the ability to implement a plugin logic that for instance let's a resource modify certain other resources based it's own current data set. Benjamin's initial thought was going further by suggesting a mechanism to provide each service with information about all available services and thus enable a service to service communication. Maybe it should be defined in which extend such functionality should be implemented. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADiF7U6s72UbgtaQ1k9j8WcsVh_uoqVZks5rvKQAgaJpZM4Lojgh> .

-- - Patrick (Mobile)

[codeundkakao]

Thinking about this further, this kind of relates to or could be the basis of #30 as well. Not sure about a smart solution though. I gotta dig a little deeper and understand viwi in it's current state a little better still.

[wzr1337]

have a look at the media/medialibrary implementation in the audio playback branch.. media uses the medialibrary

…

On Wed, Apr 26, 2017 at 11:16 PM, alexander thieme ***@***.*** > wrote: Thinking about this further, this kind of relates to or could be the basis of #30 <#30> as well. Not sure about a smart solution though. I gotta dig a little deeper and understand viwi in it's current state a little better still. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADiF7X1fgIFEJ8AIm-78CWrkQff5XrM1ks5rz7Q7gaJpZM4Lojgh> .

-- - Dr. Patrick Bartsch (web)