Perhaps we need to re-think this whole plugin system. I've so far discovered the following two issues:
1) The ApplicationLogs filters logs from uninstalled plugins by getting the object manager class name as a lower-case string and then checking to see if a plugin by that name exists. I discovered this while trying to create a "Time" plugin incorporating all the TimeTracker code. However, the object manager for application logs from that plugin is called ProjectTimes. Now, I've worked around this relatively easily by adding a column to the plugins table called 'log_providers' and asking the plugin's init.php script for a list of those. 2) Public files and images. This is a major deficiency in the current plugin architecture. The plugin can't provide any static content without writing outside the /application/plugins/ directory structure. Allowing a plugin to do so would violate the principle of isolating plugins from each other. It would also make plugins harder to add and remove completely. I discovered this because the "Wiki" plugin creates application logs, which when displayed on the dashboard tries to show an image in the left-hand column of the log entry. The wiki plugin can't distribute an image for every possible theme, though, and it would have to install that image outside of its plugin directory. Both of these situations are unacceptable. I can't solve this problem because the sequence of functions called (image_url() -> get_image_url() -> get_public_url()) makes it hard to check if a file exists and provide another default location if it doesn't. And that is not even mentioning the configuration headache installing PP would incur in getting Apache to serve public files out of another directory in addition to /public/. So does anyone have any thoughts on how to solve these two issues? Can anyone think of any further issues like this that we may encounter? I'm sure as we create more plugins we are going to run into more issues like this. We may not be able to anticipate all of them until we encounter them, which means we need a lot more people contributing test plugins. My initial fear is that adding proper plugin support to the system is going to require so many changes that it would be better to completely re-architect ProjectPier. Plugins need to be pushed into the Env classes, not some hack-job add-on. A plugin system's needs are low-level enough that they should be part of the *core* application. The same goes for extensible permissions. Plugins are making me very sad today. -- =================== Brett Edgar True Digital Security, Inc./DESA Research, LLC. [EMAIL PROTECTED] 866.430.2595 x 103 www.truedigitalsecurity.com
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Projectpier-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/projectpier-development
