Warning: Can't synchronize with the repository (Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? ). Look in the Trac log for more information.

Ticket #10 (closed enhancement: wontfix)

Opened 3 years ago

Last modified 3 years ago

nested entry points for plugins

Reported by: msfrank Owned by: msfrank
Priority: major Milestone:
Component: core Version:
Keywords: Cc:

Description

since we have (or will have) multiple types of entry points for plugins (i.e. a service entry point, config entry point, frontend entry point, controller entry point), it would be nice to be able to enable certain entry points only if a 'parent' entry point has been enabled. that sounds really confusing, here's an example:

i have a plugin for downloading torrents. the main entry point is a service, which handles the torrent downloading. i also have a frontend entry point, which displays current downloading information to the user. we should make the frontend entry point a child of the service entry point, meaning the frontend is only enabled if the service is turned on. that way, we don't see the frontend web page if torrents are not enabled.

Change History

Changed 3 years ago by msfrank

  • status changed from new to closed
  • resolution set to wontfix

i think i went overboard with this plugin redesign. there isn't really a need for arbitrary nesting of plugins. actually we should just support higgins.service.Service as an entry point for a plugin, and things like configs and frontends can just be list attributes of the service class. in the case of upnp device entry point, we should subclass the service class to do the necessary declarative field parsing.

Note: See TracTickets for help on using tickets.