slashcode-development

[Slashcode-development] [ slashcode-Patches-431439 ] A repository for plugins

[<no...@so...>]

Patches item #431439, was updated on 2001-06-08 09:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304421&aid=431439&group_id=4421

Category: MAIN branch
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alvaro del Castillo (acs2)
Assigned to: Nobody/Anonymous (nobody)
Summary: A repository for plugins

Initial Comment:
This plugin implements a system to have a common place
to put
the reference to slashcode plugins, yes, a repository
for slashcode
plugins. We have to find the best place to put it,
maybe in http://slashcode.com/plugins.pl.

This is the first version so it have some bugs sure ;-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304421&aid=431439&group_id=4421

Re: [Slashcode-development] [ slashcode-Patches-431439 ] A repository for plugins

[Brian A. <br...@ta...>]

Here are some comments I had on slashcode about this:
Good start but it needs a couple of things though. 
1) The ability for an admin to approve a plugin (AKA you just don't want
everyone adding stuff willy nilly).

2) With category there needs to be a table listing 
category (AKA so they actually make sense).

3) Someway to list changes (so update can happen).

4) Someway to have ownership, so that only the editor can make changes. 

5) RSS output so that people can use it in slashboxes.

What else do others see a need for, aka what would make this the cat's
meow?
	-Brian

Re: [Slashcode-development] [ slashcode-Patches-431439 ] A repository for plugins

[Alvaro d. C. <ac...@ba...>]

Hi!

El 08 Jun 2001 11:26:12 -0700, Brian Aker escribió:
> Here are some comments I had on slashcode about this:
> Good start but it needs a couple of things though. 

Sure, it is very basic but I have try to make it very clean and very
short so we can start to add new functionality very easily.

> 1) The ability for an admin to approve a plugin (AKA you just don't want
> everyone adding stuff willy nilly).

We have a field called active. Maybe this field can only be changed by
and admin plugin rol. We can have an ACL that controls this. It could be
a good idea to test the ACL system with this simple plugin to learn the
possibilities of the ACL system ;-) If not, we can use the seclev
system. To activate a plugin you need to have more that 5000 or 10000.
 
> 2) With category there needs to be a table listing 
> category (AKA so they actually make sense).

Yes. We can use the createSelect function in Slash and have this
categories in a table. Maybe plugins_params ;-) because I think that a
plugin will change the info related to it in the near version of
slashcode.

> 
> 3) Someway to list changes (so update can happen).

Ops, the actual interface let you change the info about a plugin if you
have introduce it. Has you seen this? Try to insert a new plugin and
then you will have to list. The general plugin in list and a little list
with the plugins that you have introduce. If you click in a plugin owned
by you, then the interface show you a form that let you change the
plugin info.

But I am not sure if you refere to this. Maybe you talk about the
changes in the plugin between different versions and the patch needed to
upgrade the plugin.

> 
> 4) Someway to have ownership, so that only the editor can make changes. 

It is now in the plugin. If your slash user has introduce the plugin you
can edit it.

> 
> 5) RSS output so that people can use it in slashboxes.

Yes, this is wonderfull :-)

> 
> What else do others see a need for, aka what would make this the cat's
> meow?

- Instalation instructions.
- The possibility to have comments about the plugins from other users
maybe using a slash story.
- The possibility for the user to give points/stars to the plugins

Cheers


-- Alvaro


>       -Brian
> 
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> http://lists.sourceforge.net/lists/listinfo/slashcode-development
> 

Re: [Slashcode-development] [ slashcode-Patches-431439 ] Arepository for plugins

[Brian A. <br...@ta...>]

Alvaro del Castillo wrote:
> and admin plugin rol. We can have an ACL that controls this. It could be
> a good idea to test the ACL system with this simple plugin to learn the
> possibilities of the ACL system ;-) If not, we can use the seclev
> system. To activate a plugin you need to have more that 5000 or 10000.
You know, I can not remember where we ended up with the debate on ACL's.
Pudge, do you remember?

> > 2) With category there needs to be a table listing
> > category (AKA so they actually make sense).
> Yes. We can use the createSelect function in Slash and have this
> categories in a table. Maybe plugins_params ;-) because I think that a
> plugin will change the info related to it in the near version of
> slashcode.
This is why code_params was created :)
Easy enough for plugins to add items for getDescriptions().

> But I am not sure if you refere to this. Maybe you talk about the
> changes in the plugin between different versions and the patch needed to
> upgrade the plugin.
Yep, I was talking about revisions.

> > 5) RSS output so that people can use it in slashboxes.
> Yes, this is wonderfull :-)
Pretty much everything should have the ability to dump data via
RSS by this point. There is a Slash::XML library that was written
for this (its only in Fry right now though, I could add a CVS module
though for people to be able to extract it and install on their
own). About a minute's worht of work.

> - Instalation instructions.
> - The possibility to have comments about the plugins from other users
> maybe using a slash story.
Comments for items like this is a fry feature, you can't really do them
well in Bender.

> - The possibility for the user to give points/stars to the plugins
Overall moderation system tied to anything in the system. 
Cliff, any thoughts on this? I would love to see someone take the
karma system and turn it into a plugin that could be used with
any item. Since moderation is now tied in Fry to discussions you
might be better off doing a seperate moderation system that
worked on entities in the database. AKA tie it to anything
with a primary key.

	-Brian

karma plugin Re: [Slashcode-development] [ slashcode-Patches-431439 ] Arepository for plugins

[shane <sh...@lo...>]

At 03:33 AM 6/9/2001 -0700, you wrote:
>Alvaro del Castillo wrote:
> > and admin plugin rol. We can have an ACL that controls this. It could be
> > a good idea to test the ACL system with this simple plugin to learn the
> > possibilities of the ACL system ;-) If not, we can use the seclev
> > system. To activate a plugin you need to have more that 5000 or 10000.
>You know, I can not remember where we ended up with the debate on ACL's.
>Pudge, do you remember?
>
> > > 2) With category there needs to be a table listing
> > > category (AKA so they actually make sense).
> > Yes. We can use the createSelect function in Slash and have this
> > categories in a table. Maybe plugins_params ;-) because I think that a
> > plugin will change the info related to it in the near version of
> > slashcode.
>This is why code_params was created :)
>Easy enough for plugins to add items for getDescriptions().
>
> > But I am not sure if you refere to this. Maybe you talk about the
> > changes in the plugin between different versions and the patch needed to
> > upgrade the plugin.
>Yep, I was talking about revisions.
>
> > > 5) RSS output so that people can use it in slashboxes.
> > Yes, this is wonderfull :-)
>Pretty much everything should have the ability to dump data via
>RSS by this point. There is a Slash::XML library that was written
>for this (its only in Fry right now though, I could add a CVS module
>though for people to be able to extract it and install on their
>own). About a minute's worht of work.
>
> > - Instalation instructions.
> > - The possibility to have comments about the plugins from other users
> > maybe using a slash story.
>Comments for items like this is a fry feature, you can't really do them
>well in Bender.
>
> > - The possibility for the user to give points/stars to the plugins
>Overall moderation system tied to anything in the system.
>Cliff, any thoughts on this? I would love to see someone take the
>karma system and turn it into a plugin that could be used with
>any item. Since moderation is now tied in Fry to discussions you
>might be better off doing a seperate moderation system that
>worked on entities in the database. AKA tie it to anything
>with a primary key.

Oh please! This would be so cool. With the comments system
being redone, and something like this, you could stick comments
on anything, as well as karma "ratings" (is ratings the correct
word?) on anything.

  Shane

[Slashcode-development] The ACL debate conclusion

[Alvaro d. C. <ac...@ba...>]

El 09 Jun 2001 03:33:18 -0700, Brian Aker escribió:
> Alvaro del Castillo wrote:
> > and admin plugin rol. We can have an ACL that controls this. It could be
> > a good idea to test the ACL system with this simple plugin to learn the
> > possibilities of the ACL system ;-) If not, we can use the seclev
> > system. To activate a plugin you need to have more that 5000 or 10000.
> You know, I can not remember where we ended up with the debate on ACL's.
> Pudge, do you remember?

I can ;-) But the actual solution is different:

- A plugin for ACLs with the ACL functions
- A plugin AdminACL that use this library


Chris Nandor wrote:
> Yeah, I was thinking about something very similar at one point, and
think
> this is a nice idea.  I wonder, though, if maybe users_param would be
a
> better user of this?  So instead of:
I would keep it out of users_param, but use the same schema. 

> Or, alternatively, implement users_acl _as_ a param-style table.  The
> problem, of course, is that we could have dozens of types of
permissions,
> and it is easier to just insert a new value than it is to change the
schema
> each time you want to add a new one (and this would make it more
easily
> extensible via the admin interface, too).  Also, a table with a few
dozen
> fields could be slower and more bloated.
The param style table is actually pretty quick for look ups. 

If the schema was modified to resemble a param table and we had patches
for getUser() and setUser() I would probably be all for including it.

It might be nice also to have a seperate table which described param's
currently in use.
        -Brian

-- Alvaro