OpenID and trac

[Dalius Dobravolskas]

Hello,

This letter is to main trac developers.

I'm author of trac OpenID plugin
(http://trac-hacks.org/wiki/AuthOpenIdPlugin). One user of my plugin
showed me bounty program http://openid.net/foundation/bounty/ that you
might be interested in. Since one requirement says that OpenID should be
core functionality of product I can't do anything myself. So I offer to
integrate my OpenID plug-in into trac and take that little prize ;) I
believe that even little amount of money will help this amazing project
(trac) to evolve and grow further.

If you decide taking this task please reconsider this ticket as well:
http://trac.edgewall.org/ticket/6429

Best regards,
Dalius Dobravolskas
http://blog.sandbox.lt

[Emmanuel Blot]

I really don't see such a plugin integrated into Trac core, as OpenID
is one feature that may not be useful for many private Trac
installations. It is not a 'core' feature, whatever the quality of the
plugin or some externalities requirements.

Cheers,
Manu

On Feb 12, 2008 7:23 AM, Dalius Dobravolskas

--
Manu

[dalius.do...@gmail.com]

On 12 Vas, 10:39, "Emmanuel Blot" <manu.b...@gmail.com> wrote:
> I really don't see such a plugin integrated into Trac core, as OpenID
> is one feature that may not be useful for many private Trac
> installations.

I agree that this argument is correct now but since OpenID adoption
grows quite fast this might be not so valid in the future. You might
reconsider OpenID in light of recent step of some big internet
companies: http://openid.net/2008/02/07/evolving-the-openid-foundation-board/

As well please note that OpenID could be even simpler to many people
than basic authentication.

Side note: I would love if I could use OpenID to login to your trac:
http://trac.edgewall.org/. Because now I can't even comment properly
(SpamAssasin thinks I'm spammer) and thank nkantrowitz for giving me
idea how to solve my problem (http://trac.edgewall.org/ticket/
6429#preview).

In case nkantrowitz is reading this group, thank you!

Best regards,
Dalius

[m...@xdsinc.net]

I would like OpenID as a plugin, but distributed with the base system,
and tested with the base system. Please see perl: it's easy to add
things, but perl doesn't come "bare" -- it comes with a number of
modules as part of the base distribution, but you have to ask for them.

OpenID should be easy to configure, but it doesn't need to be the only
answer. More and more "core" functions should use the plug in
functionality, but be distributed with the base system.

--
Michael Richardson <m...@xdsinc.net>
Director -- Consumer Desktop Development, Simtone Corporation, Ottawa, Canada
Personal: http://www.sandelman.ca/mcr/

SIMtone Corporation fundamentally transforms computing into simple,
secure, and very low-cost network-provisioned services pervasively
accessible by everyone. Learn more at www.xdsinc.net and www.SIMtoneVDU.com

[Emmanuel Blot]

> I agree that this argument is correct now but since OpenID adoption
> grows quite fast this might be not so valid in the future.

So we'll see in the future ;-)
Again, OpenID is a useless feature for Trac installation on company
LANs where several authentication back-ends already exist (think LDAP,
among others).
OpenID can be implemented as a plugin and does not require a invasive
implementation in the core

mcr wrote:
> More and more "core" functions should use the plug in functionality, but be distributed with the base system.

There is an on-going discussion about "official" plugin (vs
non-official and maintenance state unknown ones).

Cheers,
Manu

Cheers,
Manu

[Christian Boos]

m...@xdsinc.net wrote:
> I would like OpenID as a plugin, but distributed with the base system,
> and tested with the base system. Please see perl: it's easy to add
> things, but perl doesn't come "bare" -- it comes with a number of
> modules as part of the base distribution, but you have to ask for them.
>
> OpenID should be easy to configure, but it doesn't need to be the only
> answer. More and more "core" functions should use the plug in
> functionality, but be distributed with the base system.
>

Yes, I think this topic will become an important one in the coming months.

I very much agree with what you said above, I think that having a
modular system should enable us to provide a good range of optional
functionality out of the box, like numerous other successful projects
do. In my opinion, this will have many positive effects, like favor a
closer collaboration between plugin writers and core developers, ensure
a better homogeneity for a given release and also make way for a simpler
and more modular installation.

Now some brainstorming about the simpler installation part :-)

I imagine the following: right after having installed or upgraded a new
Trac environment, the last step of the installation would be to access
the environment (tracd can be used for that) and see a somewhat enhanced
plugin administration module (an installation module?), where one could
select the major subsystems, and then pick additional features,
configure them, etc.

It could look something like:

----------------------
Congratulations, you've installed Trac 0.12.

Now you can enable specific sub-systems that correspond to your needs:

|x| Wiki
|_| Bug Tracker (ticket system)
|_| Repository Browser
|_| Timeline
|_| Search
----------------------

Once the major sub-systems are selected, further plugins will be proposed.

There could also be some interaction between enabling the plugins and
modifying the plugin specific configuration settings.

Example for the repository browser sub-system:
----------------------
|x| Repository Browser
|_| Browse Local Subversion Repositories
|_| Browse Remote Subversion Repositories [EXPERIMENTAL]
|_| Browse Mercurial Repositories
----------------------
Note that we would use the [EXPERIMENTAL] warning to make it clear that
the plugin works but has potentially some rough edges, a bit like the
Linux kernel does for its drivers (or used to do - it's been a while
since I compiled my last kernel...).

Once you select one or more of the above plugins, they could also show
the configuration entries attached to them, or link to some more
specific admin panel.

Back to the specific case of the OpenID plugin, we could have something
like:

----------------------
General
Authentication Systems
(o) Default HTTP authentication
( ) Account Manager
( ) Use OpenID
----------------------
(well, I don't know much about the account manager and openid, so I'm
not sure they're on the same level or even if openid depends on account
manager, but you get the idea).

-- Christian

[Endre Bakka]

> I very much agree with what you said above, I think that having a
> modular system should enable us to provide a good range of optional
> functionality out of the box, like numerous other successful projects
> do. In my opinion, this will have many positive effects, like favor a
> closer collaboration between plugin writers and core developers, ensure
> a better homogeneity for a given release and also make way for a simpler
> and more modular installation.

I agree on all accounts. Another point I would like to make is that there
is so much uncertainty surrounding plugins that I believe many (and
especially companies) are hesitant to install them. They are hosted on a
separate site and many seem to be unmaintained (when the person writing it
loses interest - then what). I believe many select a competing system
because they need to install plugins to get the functionality they need.

I also propose that "official" plugins are called modules to emphasize the
difference between them.

> Now some brainstorming about the simpler installation part :-)

I like all of your ideas, only two comments:

1) The user should be able to select between:
- Standard (set of most common modules)
- Full (all modules)
- Custom (which would run through the menu you described)

2) All modules should be possible to be managed from the admin interface.

- Endre

[Jani Tiainen]

Christian Boos kirjoitti:

> m...@xdsinc.net wrote:
>> I would like OpenID as a plugin, but distributed with the base system,
>> and tested with the base system. Please see perl: it's easy to add
>> things, but perl doesn't come "bare" -- it comes with a number of
>> modules as part of the base distribution, but you have to ask for them.
>>
>> OpenID should be easy to configure, but it doesn't need to be the only
>> answer. More and more "core" functions should use the plug in
>> functionality, but be distributed with the base system.
>>
>
> Yes, I think this topic will become an important one in the coming months.
>
> I very much agree with what you said above, I think that having a
> modular system should enable us to provide a good range of optional
> functionality out of the box, like numerous other successful projects
> do. In my opinion, this will have many positive effects, like favor a
> closer collaboration between plugin writers and core developers, ensure
> a better homogeneity for a given release and also make way for a simpler
> and more modular installation.
>
>
> Now some brainstorming about the simpler installation part :-)

Hopefully that storm didn't damaged anything further... :-)

Setupflow described here follows pretty much something that many other
web projects I've seen use. First you install bunch of stuff, then
bootup initial (admin) environment, do standard settings and after that
you create that first ready-to-use environment.

That push it further that admin interface could contain means to create
new environments so no commandline would needed.

--
Jani Tiainen

[rupert....@gmail.com]

i'd prefer to click in webadmin - plugins, and see the ones installed,
activated, and available. clicking an available one might install it
by fetching it from the internet. and i would love if there would be a
one click activates it, especially practical with plugins with many
modules like xml-rpc.

rupert.

[David Abrahams]

on Wed Feb 13 2008, Christian Boos <cboos-AT-neuf.fr> wrote:

> m...@xdsinc.net wrote:
>> I would like OpenID as a plugin, but distributed with the base system,
>> and tested with the base system. Please see perl: it's easy to add
>> things, but perl doesn't come "bare" -- it comes with a number of
>> modules as part of the base distribution, but you have to ask for them.
>>
>> OpenID should be easy to configure, but it doesn't need to be the only
>> answer. More and more "core" functions should use the plug in
>> functionality, but be distributed with the base system.
>>
>
> Yes, I think this topic will become an important one in the coming months.
>
> I very much agree with what you said above, I think that having a
> modular system should enable us to provide a good range of optional
> functionality out of the box, like numerous other successful projects
> do. In my opinion, this will have many positive effects, like favor a
> closer collaboration between plugin writers and core developers, ensure
> a better homogeneity for a given release and also make way for a simpler
> and more modular installation.

Does this mean
http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/3142
wasn't quite as roundly ignored as I had thought by those who matter?

This looks really nice in principle. If it were MediaWiki, you'd get a
friendly web interface for configuring such things. Something like that
might work better; I don't know.

--
Dave Abrahams
Boost Consulting
http://boost-consulting.com