[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Debian-sf-users] Plugin infrastructure -- Request for comments
From: |
Roland Mas |
Subject: |
[Debian-sf-users] Plugin infrastructure -- Request for comments |
Date: |
Thu, 14 Nov 2002 19:22:14 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) |
[ 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)
- [Debian-sf-users] Plugin infrastructure -- Request for comments,
Roland Mas <=