Re: [SM-DEVEL] New plugins common directory

[p d. t. <pdo...@an...>]

> On Tue, 30 Nov 2004 14:02:19 -0800, p dont think
> <pdo...@an...> wrote:
>
>>   I am considering adding a directory called "include" inside of the
>> plugins directory.
>
> Hi Paul,
>
> I agree with Chris, I don't really see the need for that.
>
> For instance, the useracl plugin provides some backend functions for IM=
AP
> ACLs. When it is installed, and not necessarily activated in config.php=
,
> the file is there: SM_PATH . 'plugins/useracl/sqimap_acl.php'. If anoth=
er
> plugin has a requirement for sqimap_acl, it simply includes the above
> file, and states in its README that it requires useracl installed. As
> simple as that.

Sure, but the point was to try to address the need for shared code withou=
t
necessarily needing to download a totally unrelated plugin.  You're right=
,
the compatibility plugin was born out of the same (but more pervasive)
need, and in this case, I was looking for a place for code that is more
specific to a few plugins and much less related to SM itself (unlike the
compatibility plugin).

> This is the case with the compatibility plugin as well, isn't it? It ju=
st
> provides other plugins with some functions. Like a library-plugin. :)
>
> Also, if a plugin can offer _extra_ functionality based on the existenc=
e
> of a library provided by another plugin, it can check like this: (I do
> this in avelsieve and directory):
>
>   if(in_array('useracl', $plugins)) {
>
>      ... extra functionality...
>
> }
>
> Very elegant, and nicer than
>
> if(file_exists(SM_PATH . 'plugins/include/sqimap_acl.php'))
>
>
> In fact, in the first way we could have version checks as well, if the
> plugin 'version' could be made available in an array. (However,  I susp=
ect
> that doing this in every page like it is done in the administrator plug=
in
> could have a lot of I/O overhead for large installations with a large
> number of plugins.)
>
> To conclude, I like the way 'libraries' and include files can be
> distributed as easily as any other plugin.

Yeah, I think I am convinced.  I think I agree....  I think.  I just don'=
t
like having to have unrelated plugins lying around.  To use certain Vlogi=
n
functionality, for example, you need to have the multilogin plugin sittin=
g
(but not activated) in your plugins directory.  I'm not entirely satisfie=
d
with that solution.

> I suspect that you had a particular case in mind, in order to propose
> this. What was it? :-)

Someone came to me wanting to add a php-based fortune replacement for
three plugins that use fortune-like functionality.  Pretty low priority,
but that person did get me thinking about the possibilities.

Thanks,

 paul