[Martijn]

99% are not zips requests so that should be last on the list to implement

[natethomas]

99% are not zips requests so that should be last on the list to implement

I sometimes wonder if this is because devs prefer submitting other ways, or if it's because our process is set up in such a way as to make git pulls easier that zip submissions.

[Martijn]

99% are not zips requests so that should be last on the list to implement

I sometimes wonder if this is because devs prefer submitting other ways, or if it's because our process is set up in such a way as to make git pulls easier that zip submissions.

devs prefer working with code repos in my experience. Either SVN or GIT.
Sometimes they do send zip pulls but then they are in fact tagged releases on Github.

Sure code repos have a steep learning curve but so does coding add-ons. Usually they go hand in hand.

[zag]

1) Dev logs in
2) Dev uploads the add-on zip file (having same structure as earlier) on his dev portal
3) The zip XML is parsed and all meta data is displayed (or error shown) to the dev for conformation
4) On confirming dev clicks on submit
5) A Github pull req is generated at this point, and the Kodi admin gets a notification on his own user portal
6) The admin verifies the package and approves/rejects, and clicks on publish accordingly
7) Dev get a notification back on his portal

Yep thats pretty much how I would design and easy to use system as well. Most appstores will work this way. My advice is to design the system however you think is best

The only thing I would add is a check of the parsed XML that it contains a valid GitHUB link to the <source> field. This way we have the best of both worlds (as discussed in the posts above).

In the last frontend I ran(for another bit of software), we had a "test upload" feature where the zip was uploaded and xml parsed giving a check of each metadata with a tickbox and a final Success/Failure result was shown. This meant the user did not have to submit anything first and could test their add-on meets the criteria. Things that need to be checked for include:

- Unique name
- Version number
- Author name
- Source link
- Forum Link

There are probably some more as well.

[takoi]

Curse web forms! What developers (I) prefer is no forms, no pull requests, but to just type "python setup.py sdist upload" and done. IMO a backend system and an API that allow direct zip upload is where to start so that tools can be made. Then a web frontend can be added to lower the barrier to entry.

[natethomas]

Curse web forms! What developers (I) prefer is no forms, no pull requests, but to just type "python setup.py sdist upload" and done. IMO a backend system and an API that allow direct zip upload is where to start so that tools can be made. Then a web frontend can be added to lower the barrier to entry.

That'd be pretty cool too, and might ultimately result in a better developed backend.

[raptor93]

Curse web forms! What developers (I) prefer is no forms, no pull requests, but to just type "python setup.py sdist upload" and done. IMO a backend system and an API that allow direct zip upload is where to start so that tools can be made. Then a web frontend can be added to lower the barrier to entry.

This sounds even better. I'm not sure though, would this be in the scope of this GSoC project, or for the GSoC part we build a web frontend, and this we develop later on so that developers have both the options as they prefer?

[raptor93]

For the proposal, I had following ideas in my mind (after doing some research and discussion) that need to be added to the front-end.
Can someone help me categorize the features as *most important* & *less important* (or even strike off those not needed) so I can identify those to code away during GSoC?

Core:
- Migrate to a PHP framework (Symfony)
- User authentication system
- System for addon submission as I discussed in few posts before
- Developer and admin portals (a part of the previous point)

Features:
- Filter addons by the Kodi version
- Add "Recommended add-on" section for logged in users (recommendations based on user's favourite category and number of downloads)
- Rating stats (number of 3 stars, 1 stars, etc.)
- Post comments/reviews (rated)
- Add screenshot and demo video support
- Version history and changelog
- User defined tags
- Platform icon
- Social networking *share* button
- Supported languages
- Dev info

I'd love more suggestions.

[da-anda]

if you want to get crazy we could add a webservice with OAUTH2 (or whatever authentication method) that would allow to interact with the addon system. This webservice could then be used f.e. by a python script (see feature request by takoi) or even an IDE plugin to automatically publish a new addon version or update metadata etc.

[zag]

Seems you have a good grasp of things already!

In terms of priority 1) a user system, and 2) a framework migration are the things that have held this project up.

The other main features I really wanted were screenshots, ratings and comments.

Other things are nice to haves and wouldnt be too hard once the rest is done

@da-anda I think we should keep things simple at first but nice idea

[ujjwalwahi]

Hello, I am Ujjwal Wahi. I would like to work on this project and will submit a proposal.

I have done projects in PHP and familiar with jquery, mysql, python, zend. I am sure I can make good contribution to the project.

Gone through the discussion here http://forum.kodi.tv/showthread.php?tid=177783 and previous discussions in this thread.

Important thing in this project will be to provide good database design and solid code base on top of which various features can be implemented.

Symfony framework seems a good choice .

Hope to work with you guys

Thanks

[da-anda]

@raptor93
IMO the most important part is a rock solid and flexible database design, because ideally this database will be used to create our repo XML files at some point. From what you have listed, the "core" part is ofc mandatory and has the highest priority. From the "features" list I'd use this order:

• Version history and changelog (is IMO part of the core DB structure)
  
• Filter addons by the Kodi version
  
• Add screenshot and demo video support
  
• User defined tags
  
• Post comments/reviews (rated)
  
• Rating stats (number of 3 stars, 1 stars, etc.)
  
• Platform icon
  
• Supported languages (will be veeeeery tricky because most addons don't fill this info IIRC)
  
• Dev info
  
• Add "Recommended add-on" section for logged in users (recommendations based on user's favourite category and number of downloads)
  
• Social networking *share* button
  

I gave the "recommended add-on" section a pretty low priority, because I don't think we can get suiteable statistics for this. How would you determin the users "favourite category"? We don't track users nor their add-on installations, so we don't know which addons they like or what others like that have the same add-ons installed. So I'd probably rather focus on things like "newest add-ons" and "featured add-ons", where the featured part could be managed by editors that pick like 3 cool add-ons manually and write a little comment on why they are cool etc.

@ujjwalwahi
unfortunately I think only one student can work on a specific topic. But what we might need is a single sign-on system based on forum accounts (myBB) where the addon-database could authenticate against, because i think such a system is out of scope for the addon-database proposal time wise. Otoh it might also not be large enough for a GSOC project. But if you're interested you're ofc free to contribute outside of GSOC

[Montellese]

@da-anda: Multiple students can hand in projects with a similar scope. It's then up to the organization to decide which one is better suited. Obviously chances of being accepted is higher if the student projects differ.

[raptor93]

In terms of priority 1) a user system, and 2) a framework migration are the things that have held this project up.
The other main features I really wanted were screenshots, ratings and comments.
Other things are nice to haves and wouldnt be too hard once the rest is done

Yeah that is pretty much what I thought. I'd keep the other features in an "extended list", which will be implemented as the time permits.

IMO the most important part is a rock solid and flexible database design, because ideally this database will be used to create our repo XML files at some point. From what you have listed, the "core" part is ofc mandatory and has the highest priority.

Absolutely! A solid DB design is always implicitly of top priority in any software.
So from the "Core" list, I understand first two are of top importance. What would you comment on the priority of the "New web interface for add-on submission" that I discussed a few posts back?

I gave the "recommended add-on" section a pretty low priority, because I don't think we can get suiteable statistics for this. How would you determin the users "favourite category"? We don't track users nor their add-on installations, so we don't know which addons they like or what others like that have the same add-ons installed. So I'd probably rather focus on things like "newest add-ons" and "featured add-ons", where the featured part could be managed by editors that pick like 3 cool add-ons manually and write a little comment on why they are cool etc.

Ah, alright! I was not aware of the fact that we won't track users for their add-on installations.

[da-anda]

@raptor93 - addon submission proposal sounds good. This should be coded quite abstract though, so that there is a main Add-on submission manager (doing the validation part, creating PR, ...) and DataProviders/Interfaces that feed and interact with this manager. The first DataProvider would be the webform then, but if done right we could easily add a REST webservice later or whatever may come.