Coding Standards

Post by **garvinhicking** » Sun Jul 15, 2007 10:54 pm

Hi!

I've drafted some text here: http://www.s9y.org/217.html

Comments? Additions?

Regards,
Garvin

stm999999999 · Post by **stm999999999** » Mon Jul 16, 2007 9:33 pm

good idea!

some remarks:

documentation_XX.html file.

this is new, in't it?

By default, a s9y plugin is BSD licensed.

hm, if I have a look at http://spartacus.s9y.org/index.php?mode ... s_event_en most (all?) plugins are GPL.

Only use SQL statements that work in PostgreSQL, SQLite and MySQL.

We have already code that works only with Mysql - this code is even in the s9y-core (image moving

)

I think we should not have sql-indipendant as a must but should - it has to be a must to declare such dependicies! And to have a if mysql-cause in the code

Ruhe · Post by **Ruhe** » Mon Jul 16, 2007 9:40 pm

This could mean that I possibly can't use a plugin only because I'm using a database other than MySQL?
A plugin should work with and on every database.

mgroeninger · Post by **mgroeninger** » Tue Jul 17, 2007 4:40 am

hm, if I have a look at http://spartacus.s9y.org/index.php?mode ... s_event_en most (all?) plugins are GPL.

I specifically haven't put license files in my plugins because I wanted them to be BSD (or even less restrictive).

The website says they are GPL because it defaults to that if there is no propbag for "copyright" specified. I kind of feel that should change, but you run into a problem that I have been un-easy about for a while.

Unfortunately, a lot of the plugins I have worked on lately use other libraries that are licensed in other ways.

While I have kept the original license files in place on libraries (and tried to separate them out in directories), I have been reluctant to put a "$propbag->add('copyright', 'BSD License');" on anything that bundles libraries with other licenses.

I would like a little definition as far as how we handle that, even if it is to do something like

Code: Select all

$propbag->add('copyright', 'Plugin: BSD.  Bundled libraries contain GPL code.');

It might be better to have the spartacus site default to something like "Please see bundled license (if available)" instead of "GPL". It might prevent code from being mis-licensed.

Also, I am kind of with Ruhe that SQL should make every attempt to be multi-platform. (The large plugins I have done have sacrificed a lot of speed in order to stay platform neutral. I've hopefully made up for it by caching responses with Cache/Lite.)

That being said, I know that that is not always possible when you are trying to implement specific features (the usergallery plugin has a mysql specific feature of showing related posts). I think Stephan is right that we need to make a clear distinction as to what features are supported on a specific platform.

If some feature of a plugin only works on one platform it should be easy for users to see that that platform is a requirement for the feature.

I have not made any such notes in the past, but a plugin documentation system makes it a lot easier to provide those types of notes.

Updated- I've used Stephan's name enough I shouldn't be forgetting it... Sorry about that Stephan!

Post by **garvinhicking** » Tue Jul 17, 2007 11:01 am

Hi!

documentation_XX.html file.
this is new, in't it?

Yes!

hm, if I have a look at http://spartacus.s9y.org/index.php?mode ... s_event_en most (all?) plugins are GPL.

You're right. The spartacus plugin defines plugins with empty licensing as GPL. I've changed that to read "N/A (=GPL)" in the future.

Only use SQL statements that work in PostgreSQL, SQLite and MySQL.
We have already code that works only with Mysql - this code is even in the s9y-core (image moving )

Yes, but I mentioned that the code should fork if functionality only works in one of the database systems. Plugins should not FAIL if they are executed on foreign DBs, because some functionality does not exist in others, and it should still be usable if the plugin likes to.

I think we should not have sql-indipendant as a must but should - it has to be a must to declare such dependicies! And to have a if mysql-cause in the code

No, I really want to force plugin developers to use generic SQL. Lazy developers would otherwise use MySQL syntax where not really required.

Matt: Please change the 'license' propbag in that case for the plugins you've worked on? If external GPL libraries are BUNDLED, then you CANNOT make the Plugin 'BSD' code. GPL specifically forbids that. If GPL is involved, it is viral, and thus all depending code must be GPL compatible. BSD isn't.
Regards,
Garvin

mgroeninger · Post by **mgroeninger** » Tue Jul 17, 2007 4:31 pm

garvinhicking wrote: Matt: Please change the 'license' propbag in that case for the plugins you've worked on?

I haven't used a propbag anywhere there is a conflict, so nothing needs to change. It might make sense to add a propbag in places, but I have been very careful not to relicense code. (In fact, a quick glance looks like none of the the additional plugins uses the "copyright" propbag setting.)

I am very aware of the problems of the different code licenses, and, while I deeply dislike the viral aspect of the GPL, I would never purposefully violate the GPL.

Also, I'm not one hundred percent sure I agree with

If external GPL libraries are BUNDLED, then you CANNOT make the Plugin 'BSD' code.

I believe that is easier, but I think the clearly labeling licensed components would allow us to split license by file or directory. But if you believe this is untenable to support and don't want to do this with the plugins, I'll abide by that (how ever much it hurts to see my code go GPL).

stm999999999 · Post by **stm999999999** » Tue Jul 17, 2007 11:34 pm

Ruhe wrote:This could mean that I possibly can't use a plugin only because I'm using a database other than MySQL?

yes, there can be plugins or functions of plugins which need mysql.

A plugin should work with and on every database.

No.

Or in better words:

SHOULD - yes
MUST - no!

if there is a feature which needs mysql, we have two ways: give this feature to no one or give it to mysql-user. Give it to no one would be the bad way in my opinion.

But of course: if there is an easy way for a feature with mysql and a hard (complex and cpu expensive) way without, we should use

Code: Select all

if mysql do it the easy way else do it the hard way

stm999999999 · Post by **stm999999999** » Tue Jul 17, 2007 11:43 pm

mgroeninger wrote: Updated- I've used Stephan's name enough I shouldn't be forgetting it... Sorry about that Stephan!

Äh, OK, perhaps my english is not good enough: What do you mean?

mgroeninger · Post by **mgroeninger** » Tue Jul 17, 2007 11:48 pm

stm999999999 wrote:Äh, OK, perhaps my english is not good enough: What do you mean?

*laugh* your english is fine... I originally just used your account name (stm999999999) to refer to you... when I re-read it I decided I really should call you by your real name, since I know what it is and all.

Sorry about the confusion.

stm999999999 · Post by **stm999999999** » Wed Jul 18, 2007 12:08 am

*laugh* your english is fine...

Thanks!

But tell this to my former english-teacher.

I originally just used your account name (stm999999999) to refer to you... when I re-read it I decided I really should call you by your real name, since I know what it is and all.

or name me stm9x9 like Garvin

Sorry about the confusion.

never mind