[geeklog-modules] Geeklog plugin API Enhancements

[Tony Bibbs]

You'll be happy to know that GL2 will support threading of anything in any 
order.  Not sure how many of you were in on those discussions but the 
concept behind GL2 is simple.  Everything on the front page is considered 
an 'item'.  An item is just an abstract object that holds some 
characteristics common to all plugins (uid of owner, gid of group, GL 
security stuff, date posted, status (i.e. is it a submission or not), etc.

So, if you will, imagine a page where you can post an article, then 
instead of just comments you can attach polls, documents, etc.

As for arbitrary user attributes, GL2 may need to consider supporting some 
sort of registry where modules can register user attributes that other 
modules may want to use. 

--Tony
 
On Thu, 2 Jan 2003, Tom Willett wrote:

> > 1) New API to support a center block
> > I would like to see a Plugin API call in index.php to check to see if any
> > registered plugins have a function for a centerblock.
> > 
> > Possibly the lib-plugins.php function would be
> > PLG_TopCenterBlock($topic,$homepage=true);
> > 
> > Then the plugin function would be responsible for any security checks and
> > return the formated HTML. Block Developers could easily tap into this as
> > well by releasing the plugin as a basic plugin with possibly just a simple
> > install, uninstall and this block function. Need to support some concept of
> > order when there are several.
> > 
> I like this -- it is a step toward making the stories just another block and 
> turning the center into another block column.  The big problem I see here is 
> order.  It would be essential to use the block order number and that 
> complicates programming such a beast.  You would have to call all the 
> plugins and keep the results in an array until you got ready to display it.  
> Along with this, what if I want to make my block come after the stories or 
> after the main story? and before the rest of the stories?
> > 2) Usersettings API's to allow plugins to extend the usersettings in the
> > account information.
> > 
> >    - Need a API called on user (add/edit,delete,display)
> >    - Plugins could add there functions as required and keep there user
> > settings in separate tables but linked via UID
> > 
> The problem I see here is collisions -- what if two plugins want the AIM 
> username?  You have two problems that could arise here -- a variable name 
> collision and requiring the user to enter the information twice.  How about 
> a compromise.  Build the extensibility into geeklog and have one master list 
> and one master table that the plugins could use through an api.  So we could 
> have three api calls:
> 
> two for setup:
> PLG_getUserSettings           to return the list of extended user settings.
> PLG_addUserSetting            to add a user setting to the list.
> 
> one for normal use:
> PLG_getUserSetting            to read an extended user setting
> or
> PLG_getUserSettings           to read all extended settings (fewer db calls)
> 
> > 3) Story related Link ....
> > 
> >    - Plugins could be called and be related to a story.
> >    - Example: Link at end of story intro - to start a new forum discussion
> > (or view the current disussion)
> > 
> >   - This may make sense more for the forum plugin but should we make it
> > generic and topic specific. Maybe some sites may use a particular topic 
> area
> > and want the  stories related to a plugin.
> > 
> 
> Good idea.  But I see uses well beyond the forum plugin, infact beyond 
> plugins.  How about an easy way to add anything to the what's related box.  
> Then you would not have to include hyperlinks in line in text, they could 
> just be entered in the what's related box.
> 
> Actually this seems to me a geeklog core issue and not one for a plugin api.
> 
> 
> And now I will bring up another plugin issue.  The requirement that the 
> plugin be in a directory that corresponds to its name is a serious 
> deficiency.  It causes 3 problems as I see it.   1)  What about two plugins, 
> written by different authors with the same name but different purposes?  2)  
> What about name collisions with system directories  (I have run into this 
> with my stats plugin).  3)  Limitations on a descriptive name for the 
> plugin.  The easiest way around this is to add a field to the gl_plugins 
> table that has the directory the plugin resides in.  It would then be simple 
> to find the plugin and make it easy to put the plugin in different directory.
> 
> --
> Tom Willett
> tomw at pigstye.net
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules
>