[geeklog-modules] Geeklog plugin API Enhancements

[Blaine Lang]

Another API is from a note that Tony made sometime ago. GL now has a
COM_emailUserTopics() function but as the Plugins advance, we need a way for
a user to request a summary of all new site activity.

Plugins could have as fine a control for their users as they want .. but the
lib-common function needs to make a call to PLG_pluginEmailupdates()

Do we need a API call for plugins that is called when users login and
logout?

Any more ideas?

Blaine

----- Original Message -----
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-modules at lists.geeklog.net>
Sent: Thursday, January 02, 2003 10:21 AM
Subject: Re: [geeklog-modules] Geeklog plugin API Enhancements


> 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
> >
>
> _______________________________________________
> geeklog-modules mailing list
> geeklog-modules at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-modules