[Debian-sf-devel] Plugin infrastructure -- Request for comments

[Roland Mas]

[ Cc:ing -users for information purposes.  Dear users, you are the
  people we work for, do not hesitate to participate in the
  discussion, only please do so in the -devel list.  See Reply-To. ]

  Hi all,

  The good news: Kikov seems eager to integrate some sort of calendar
in our Sourceforge package.  Apparently he already has a patched
package available.

  The bad news: but I don't want to integrate his calendar in
Sourceforge.  I don't believe it's generally useful to all the
Sourceforge users.  Sourceforge is primarily a tool for open source
development, or at least open source-like development.  And we hackers
have never had any use for calendars and plannings and meetings and
such.  I know that Sourceforge is getting used in at least a few
companies or organisations, and *they* might need or in have use for a
calendar, but I still don't want to integrate phpicalendar into
Sourceforge.  Especially since there might be better calendars
available out there.

  Now don't despair, here comes the really-good news.  Not integrating
*any* particular extension doesn't mean you won't be able to use these
extensions, just that they won't be installed by default.  The keyword
there is either plugin or module, and I think I'll keep the "plugin"
word.  And I've thought about how to make those plugins working, and
I've had a few ideas.  I'm submitting these ideas here to gather
feedback and comments, so that gets to be the really-good and not the
ugly.  Here goes.

Proposal for easy integration of plugins in Sourceforge
-------------------------------------------------------

1. New tables in the database schema: I have added the following SQL
   commands in a block in db-upgrade.pl:
,----
| CREATE SEQUENCE plugins_pk_seq
| CREATE TABLE plugins (plugin_id integer DEFAULT 
nextval('plugins_pk_seq'::text) NOT NULL, plugin_name character(16) UNIQUE NOT 
NULL, plugin_desc text, CONSTRAINT plugins_pkey PRIMARY KEY (plugin_id))
| CREATE SEQUENCE group_plugin_pk_seq
| CREATE TABLE group_plugin (group_plugin_id integer DEFAULT 
nextval('group_plugin_pk_seq'::text) NOT NULL, group_id integer, plugin_id 
integer, CONSTRAINT group_plugin_pkey PRIMARY KEY (plugin_id), CONSTRAINT 
group_plugin_group_id_fk FOREIGN KEY (group_id) REFERENCES groups(group_id) 
MATCH FULL)
| CREATE SEQUENCE user_plugin_pk_seq
| CREATE TABLE user_plugin (user_plugin_id integer DEFAULT 
nextval('user_plugin_pk_seq'::text) NOT NULL, user_id integer, plugin_id 
integer, CONSTRAINT user_plugin_pkey PRIMARY KEY (plugin_id), CONSTRAINT 
user_plugin_user_id_fk FOREIGN KEY (user_id) REFERENCES users(user_id) MATCH 
FULL)
`----

   This creates three new tables.

   "plugins" lists the installed plugins, with a numeric id
   (variable), a string handle (say, "foo") and a plugin description.
   Maybe adding a plugin version could be useful, but not necessarily
   (see below).

   "group_plugin" is a way to store the fact that a group "uses" a
   plugin without needing to add a "uses_foo" to the groups table for
   each known plugin.

   "user_plugin" is the same, for users.

2. New functions in Group.class and User.class: I have added a
   usesPlugin() method to both the User class and the Group class.  It
   takes a single parameter, the "foo" identifier for the module, and
   returns a boolean if the particular user/group has turned on the
   use of that module.

3. A plugin may create its own tables in the same database.  These
   tables must be named plugin_foo_* if the plugin's string identifier
   is "foo".  One suggested table is plugin_foo_meta_data, which could
   be used to store the plugin version or something.  Maybe that table
   could be recommended instead of simply suggested, so that the
   plugins can use some code like db-upgrade.pl if its database schema
   changes over time.  These tables may have foreign key referential
   integrity constraints going from them to standard tables, but not
   the other way round.  If they have, then a command/script/something
   must be provided so that the main db-upgrade.pl can disable the
   constraints and re-enable them afterwards in case some database
   schema changes are needed.

   Similarly, a plugin may create sequences, indexes, views, etc,
   provided that their names are prefixed with plugin_foo_ too.

   A plugin should not modify the data in tables that do not belong to
   it (needs discussion, there might be cases where it's
   needed/useful).  Reading those data is okay, but it must be careful
   not to leak any info to places/users which normally wouldn't have
   had access to it.

4. We the Sourceforge-proper maintainers will maintain some sort of
   list of allocated plugin names so that different plugins get
   different allocated identifiers.

5. A plugin should not change the existing pages, except insofar as it
   adds links to its own pages.  I think these pages should reside in
   the /plugin/*/ URL-space (that is, plugin "foo" will probably put
   its files in /usr/lib/sourceforge/www/plugins/foo/), unless some
   better idea is found.  Of course, these additions will have to be
   merged into the pages of the main package, but it should be just a
   matter of inserting lines like
,----
| if $this_group->usesPlugin("foo") {
|    echo [Link to /plugins/foo/index.php?parameters]
| }
`----
   in the existing pages.  Most plugins will probably only add these
   links on the project summary page and/or on the user personal
   pages.

6. If possible, and as much as possible, a plugin should use the
   layout functions defined by Sourceforge (Layout.class, HTML.class,
   or whatever they're called), to ensure a consistent look and
   themability.

7. Of course, point 6. only applies to plugins written in PHP.
   Plugins written in other languages are not excluded by this
   proposal, and I see no need to restrict them.  Should they appear,
   they might need to recode some of Sourceforge's functions in Perl.
   I see no need to restrict that either.  Only thing: it would be
   better if the porting were as straightforward as possible.  Do not
   reimplement, please.  Just translate from PHP to Perl or whatever.

9. Speaking of languages...  I'll have to think about some way to have
   plugin-specific language files, so that the plugins can use the
   standard methods used elsewhere in Sourceforge.  I haven't thought
   about that very deeply yet, but I think it will evolve into a
   recommendation that the "handles" in the language files are
   plugin_foo_page / item (as compared to the current page / item
   model used for "core" Sourceforge i18n strings).

10. When all this has settled down, I will write a README.Plugins file
   explaining all that was decided.  I will also most probably write a
   sample plugin ("helloworld" maybe).

---- End of proposal.

  If/when all that happens, here's a list of some interesting plugins
that could be good additions to Sourceforge:

- A calendar thingy, as mentioned earlier, would be useful for
  enterprises.  I'm not a great fan of those things that allow people
  to schedule my meetings, but I acknowledge that some companies might
  be interested.  Kikov seems to have tested Phpicalendar, so that
  would be a good candidate.

- a plugin to make nicer reportings about bugs and/or tasks.  Maybe
  something to draw nice charts, maybe something to view bug/task
  dependencies graphically (a Gantt diagram?), maybe some historical
  curves showing the evolution of open bugs, whatever.  My first
  answer when I googled for "gantt diagram" was TUTOS, which seems to
  have already implemented that.  It might be possible to adapt their
  Gantt system as a plugin (actually, it seems that there are several
  things that could be stolen from them).

- a time-tracking system.  Same thing, could be stolen from TUTOS.

- a better CVS interface.  The current system uses CVSweb, but I think
  I like ViewCVS better.  It could be provided as a separate package,
  using the plugin system.

- I have other ideas too, but I'll keep them for myself until I am
  convinced they are not completely crazy or useless :-)

- Your Own Idea here.

  There.  I'm sorry for the long mail, but I thought I'd share my
thoughts on that.  Please share your comments too, so that we can get
it right (as much as possible) from the start.  I know there are holes
in that proposal, but this is really only a first draft and I (we)
will fix the problems in time.  Before committing too seriously about
anything, at any rate.

Roland.
-- 
Roland Mas

One... two... one, two, many, lots!
  -- Lias, in Soul music (Terry Pratchett)