May I suggest that whoever integrates the plugins into the main branch, will reject any contribution lacking localization and documentation.
Hack, some are lacking the author's email, not to mention the version they support !
I realize it's only a temp repository, but remember that there is nothing more permanent than that :)
Hi,
I empathize with your concerns and agree that a minimum of documentation is important and reasonable. I actually may be the guilty owner of one of the very plugins you are talking about.
Do you mean plugins should have easy to localize strings or that the plugin developers should initially contribute those strings?
I think that localization is important and it is reasonable to expect that plugins are prepared to have their strings localized, but that it is unreasonable to expect plugin developers also have the linguistic resources to provide translations.
Version support has only just become an issue, because 3.1 is only the second release with support for plugins at all. Perhaps we should discuss formalizing plugin version support in the plugin api?
Cheers, Ziba
On Tue, 03 Nov 2009 01:25:47 +0200, Moish moish@mln.co.il wrote:
May I suggest that whoever integrates the plugins into the main branch, will reject any contribution lacking localization and documentation.
Hack, some are lacking the author's email, not to mention the version they support !
I realize it's only a temp repository, but remember that there is nothing more permanent than that :)
ziba wrote:
Hi,
I empathize with your concerns and agree that a minimum of documentation is important and reasonable. I actually may be the guilty owner of one of the very plugins you are talking about.
Do you mean plugins should have easy to localize strings or that the plugin developers should initially contribute those strings?
I think that localization is important and it is reasonable to expect that plugins are prepared to have their strings localized, but that it is unreasonable to expect plugin developers also have the linguistic resources to provide translations.
Version support has only just become an issue, because 3.1 is only the second release with support for plugins at all. Perhaps we should discuss formalizing plugin version support in the plugin api?
Cheers, Ziba
On Tue, 03 Nov 2009 01:25:47 +0200, Moish moish@mln.co.il wrote:
May I suggest that whoever integrates the plugins into the main branch, will reject any contribution lacking localization and documentation.
Hack, some are lacking the author's email, not to mention the version they support !
I realize it's only a temp repository, but remember that there is nothing more permanent than that :)
my 2c
I agree that plugins should always allow for localization. It's
trivial to do, so there is no reason not to do it.
The rest I all dont agree with at this stage in the APIs development.
Not only is roundcube still in a 0.x release, the API is still not
fully settled. People have requests for hooks, and other elements of
the API regularly. People need to be able to play with the API and
see as many examples as possible, and arbitrary rules that plugins
have to adhere to before being published is just counter-productive as
this stage. The plugins themselves are currently acting as
documentation. For that reason I try to document my plugins as much as
I can in the code itself (see for instance my compose_addressbook
plugin that uses many of RCs cool features like ajax back and forth
communication). If you want to play with plugins right now, be
prepared to read the code and learn. Also be prepared to come to the
API Plugins section in the forums where most plugin authors lurk.
It would be a good idea for future development to allow for a version
check in the API. But I would be careful on how strict to apply it.
Plugins are more often than not abandonware, fire and forget. But that
doesnt mean they cant still be useful many releases into the future.
The only way you would want to be strict is in applying a minimal
version your plugin needs. You absolutely dont want to be strict on
the highest version your plugin supports, as that causes chaos as RC
upgrades (except for the few plugins that RC ships with).
I do think we'll see a plugin repository in the not too distant
future, and when that happens i fully agree we can be more strict with
plugins. Until that time, be glad people are even making plugins. Most
plugins dont need much documentation and are easy to figure out.
Cor
List info: http://lists.roundcube.net/dev/
RC is not a playground anymore ( well, it may still be playing, but with the big boys now :) . It may be intimidating but I'm pretty sure it makes some people proud.
I'm not complaining and I know how busy everybody is. All I'm saying is that anything that's released in the main branch should follow "barebone" standards.
Moish
List info: http://lists.roundcube.net/dev/
RC is not a playground anymore ( well, it may still be playing, but
with the big boys now :) .
We run it in a production environment with over 50,000 accounts (the
other 800,000 are still on squirrelmail) and about a 1000 concurrent,
but i do realize we're taking a risk. I wouldnt use it if i didnt
think it was ready for this, but at the same time, i know it's still
only a 0.x release.
It may be intimidating but I'm pretty sure it makes some people proud.
Rightly it should. RC is a very well designed project from a
developers point of view.
I'm not complaining and I know how busy everybody is. All I'm saying is that anything that's released in the main branch should follow "barebone" standards.
Ok, i suppose I do agree with that upto a point. If the developers add
a plugin to the main SVN branch, it should have localization support
at least. Else it gives a bad example, and as a plugin developer
myself I look to those examples in SVN all the time to see code
snippets.
Cor
List info: http://lists.roundcube.net/dev/
Cor Bosman wrote:
RC is not a playground anymore ( well, it may still be playing, but
with the big boys now :) .We run it in a production environment with over 50,000 accounts (the
other 800,000 are still on squirrelmail) and about a 1000 concurrent,
but i do realize we're taking a risk. I wouldnt use it if i didnt
think it was ready for this, but at the same time, i know it's still
only a 0.x release.
As a maintainer of a similarly sized RC installation, I'm OK with parts of RC still being a bit of a playground.
The core architecture is very good, but there are several areas which will take more time to flesh out. I'd rather go through the pain and confusion of shifting apis than slow down the rate of change. At least for the next few releases.
Best, Ziba
List info: http://lists.roundcube.net/dev/
On Tue, Nov 3, 2009 at 12:25 AM, Moish moish@mln.co.il wrote:
May I suggest that whoever integrates the plugins into the main branch, will reject any contribution lacking localization and documentation.
Hack, some are lacking the author's email, not to mention the version they support !
I realize it's only a temp repository, but remember that there is nothing more permanent than that :)
+1
I'm working on a repository and I plan to demand a package.xml from everyone who contributes a plugin. I could demand that at least one of the files in there is of type/role doc. Still, if the file is empty, etc.. There's always ways around it.
Generally, I also agree that RoundCube could advertise a PluginAPI version. But in the end, please keep in mind that we're 0.3.1 for a reason. ;-) It's not 3.1, but 0.3.1.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/