Plugins' usability

[Moish-3]

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 :)

--
Moish

_______________________________________________
List info: http://lists.roundcube.net/dev/

[ziba]

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@...> 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 Scott
_______________________________________________
List info: http://lists.roundcube.net/dev/

[Moish-3]

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@...> 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. En_US strings at least.
2. Api are formalized by definition. Version check against api
    is critical.
3. Minimal documentation at Admin level is critical.

my 2c

--
Moish

_______________________________________________
List info: http://lists.roundcube.net/dev/

[Cor Bosman]

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/

[Moish-3]

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/

[Cor Bosman]

> 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/

[ziba]

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/

[tfk]

On Tue, Nov 3, 2009 at 12:25 AM, Moish <moish@...> 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/