Some progress pics.

LouisGac wrote: we could say: "XML is an API".

During the XML hype we used to say: XML has schema. That was around 2000, where XMLSpy was one of the few editors to cope with XML. Old times.

@olle:
Nice, but is "Purchase" the right word if there are free (GPL etc) plugins too?
What's about "Get" or "Find"?

olle wrote: Some progress pics.

Oups, i think it was included in Plugin Management to add 'update' link for example.

DenisChenu wrote:

olle wrote: Some progress pics.

Oups, i think it was included in Plugin Management to add 'update' link for example.

We'll get there.

orvil wrote: @olle:
Nice, but is "Purchase" the right word if there are free (GPL etc) plugins too?
What's about "Get" or "Find"?

Good suggestion, will fix.

orvil wrote: @olle:
Nice, but is "Purchase" the right word if there are free (GPL etc) plugins too?
What's about "Get" or "Find"?

I agree with that statement.

Some more pics.

Files are no longer scanned automatically. You have to manually click "Scan files" to check for available plugins. This will not be the preferred installations method. Instead, you should either upload a ZIP package or browse available plugins etc in the store view.

Go Olle, go!

LouisGac wrote:

orvil wrote: @olle:
Nice, but is "Purchase" the right word if there are free (GPL etc) plugins too?
What's about "Get" or "Find"?

I agree with that statement.

And I would even go so far to not call it "shop" at all, but "Extensions" or whatever.

Since themes (surveys & questions) are part of the game, I would suggest "add-ons". But when you think about finding a suitable term in other languags "extensions" might be better.

If I get the intention of the shop right, the add-ons should be only offered inside of the LimeSurvey application. The store should not simple replace the function of the Joomla file repository (LimeSurvey.org -> Downloads).

If the user should be able to use add-ons without manual downloading and installing them, the way LimeSurvey and add-ons are offering updates gets a lot more critical.
More users will install more add-ons. Will e.g. ComfortUpdate analyze these add-ons? Will ComfortUpdate deactivate all add-ons during update? Or will ComfortUpdate access all add-ons for version compatibility upfront and demand update of add-ons first? The release early, release often approach in combination with an add-on shop will demand some change to get along smoothly.

Will there be a system to select the correct versions of add-ons? Upgrade/Downgrade of plug-ins? Or themes?
Long term aim: Packaging? research.swtch.com/vgo-mvs / blog.golang.org/versioning-proposal

Currently a LimeSurvey user has to have some knowledge to choose, download and install a plug-in. If a plug-in breaks e.g. LimeSurvey login, you could be sure that the user had access to the file-system. Removing plug-ins from the folder would be the current quick fix.

The theme and plug-in developers might have some questions about offering items too. Will the addon-shop be more like Wordpress (SaaS via Wordpress and external payment when selfhosted) or more like Apple App-Store (Payment via Store only). Who will handle the payment is a interesting part. Add-ons could be offered via a freemium business model and a key could be sold to upgrade a add-on. Personally I would like to see a central payment and product bundles to get transactions easier handled. Like Themeforest has done to the Wordpress theme market. But I have no idea how many developers are interested in the distribution via a central shop.

1) If I get what I want, there will be a plugin shop both in the installation and on limesurvey.org. Payments will always be done on limesurvey.org, though.

2) Plugins available in our shop will be certified and controlled by us, and the authors will be legally responsible for security issues etc.

3) No events are executed during ComfortUpdate, so no plugin code can run during the upgrade.

4) The plugin manager has been hardened with shutdown control that automatically disable plugins that have critical errors, like syntax errors or "Class not found".

5) All plugins HAVE TO include a config.xml file with compatibility information. Plugins that are not compatible will automatically be disabled.

6) If a plugin breaks the login procedure you're screwed. yes.

Hope this answered some of your questions. It's still a draft, but we hope to achieve something along these lines.