composer.json only vs composer.json + module.json

[vitorbrandao]

This is a "discussion" issue so we can throw our arguments.

For each module, besides the Github url (or any other URL), packagist name, we may want to store extra data like screenshots. To store this extra data we would need another file made specially for the marketplace.

I'm all against duplication and extra effort so I would like the most of the data from composer.json and the README.md but I'm not sure if we can live with a module.json or similar. Better take a look at Zend, Joomla and others before rolling out our implementation.

What about paid modules?

[code-ph0y]

Well Joomla uses ZIP files with a XML file and an upload feature and their Extensions Directory allows you to put external links too download/demo the Extension meaning the external website deals with the payment of the paid modules.

Which brings another question do we want to provide demos?

As for the paid modules it might be an idea to adopt e-commerce features and a dashboard showing your revenue?

As for now I think the idea is to use the sites create module to add in the screenshots, description and other data about the module.

[code-ph0y]

We could also take a percentage for each module that a user buys?

[vitorbrandao]

I would like to focus right now only on the technical details of the implementation leaving an open door for paid modules but not discussing the business model (PPI is an open source framework, not a pro-profit company).

My goal is to make it very easy for folks to create PPI modules and make them available in the marketplace. And the less they need to add compared with a non-marketplace module the better.

OK, now a controversial suggestion: what about annotations in Module.php? Phalcon and Doctrine have annotation parsers we could use for this task.

[code-ph0y]

Agreed if we can get the open source modules working on the system first then we can look at paid modules later

I think its back to the drawing board then with regards to entering the modules into the system do we want the process to be automated and if we do how can we get around not uploading the modules on to the server?

[vitorbrandao]

We should implement GitHub login and lookup for PPI modules in the user's account and also allow the user to register a specific git URL. After the repo becomes available it is just a matter of collecting all the data we need from Module.php, composer.json, README.md, LICENSE) and publish it on the marketplace.

We just need to think a little bit about how to properly categorize each module. Example: PlatesModule should be in the "Templating Engines" category (could belong to others). We could guess based on composer tags, class inheritance, project description or force the user to explicitly pick our PPI-defined categories and write it down somewhere in the module (metadata.xml, Module.php via annotations, other?).

[dragoonis]

1) Not discussing paid modules, if this was to happen it would probably be a separate website like "premium-ppi-modules-website-here.com", since PPI is open source then we'll only be working on functionality right now.

2) Screenshots, we can (for now) have the users manually upload their screenshots via the web UI when creating your module.

3) I like the idea of ppi.json or ppi_module.json - This will contain the categories/tags/information that's custom only to their PPI module. The users might not have it up on packagist and we must respect this as an option and not a requirement.

4) When the user makes their module we ask them for a Github URL or a Packagist URL.

• Packagist URL

If they have a packagist URL, we can pull in their github URL, categories, description ..etc

• Github URL If they have a ppi.json file in their repo we can use this for extra functionality that exists on the PPI Marketplace but not on packagist. Anything in the ppi.json file such as description will override settings in their packagist url