A couple of months ago I came up with a proposal for how an Ubuntu Component Store could work to be a place where people could upload self-contained components for Ubuntu SDK apps, after a long discussion with nik90 about it all. However, it requires a server which maintains accounts and so on, and that’s hassle. So, an alternative idea, which is a bit more limited but also quite a bit more doable, I think.
We still go with core, curated, and community components as in the above proposal, and this is only about community components. They are still called username/componentname as before. But now, they must be hosted on Launchpad.
What you do, to build a component, is you push a branch to Launchpad. That branch must have the following things in it:
/ubuntu_component_store.json- a JSON manifest describing your component. More on this later./ubuntu_component_store- a folder in which all the bits of your component live/ubuntu_component_store/bin/arm-linux-gnueabihf/$COMPONENTNAME.o/ubuntu_component_store/bin/i386-linux-gnu/$COMPONENTNAME.o/ubuntu_component_store/bin/x86_64-linux-gnu/$COMPONENTNAME.o- any compiled parts of your component go inbin/$arch/as binary compiled files/ubuntu_component_store/qml/$WHATEVER.qml- any QML files for your component (and any external files that they depend on, such as images) go inqml/
Obviously if your component is only a binary QML plugin then it won’t have a qml folder, and if it’s pure QML then it won’t have a bin folder. Note that bin contains compiled plugins, not source. You should have a way of letting people get the source for your component, especially if they want to change it or improve it, but that’s not what this is about: ucs install gets a working binary thing. It does not get the source so that you compile it yourself, because it’s aimed at people who don’t want to do compilation at all. (In particular, a pure QML project won’t have any of the cmake stuff even set up, and it should not have to have.)
The binary arch stuff is designed to fit in with fat packages properly.
You then submit the component to the server, with ucs submit lp:~username/project/branch, passing the LPURL for the branch you pushed. The server fetches ubuntu_component_store.json from the root of that branch and parses it for metadata; it may also check that the branch looks validly like a component. The server then updates community_components.json, which is a file listing all metadata for all the community components, and uploads it back to Launchpad. (It’s a bit like a Debian Packages file.)
Then a developer decides to use your component, so they ucs install name/yourcomponent. This fetches community_components.json from Launchpad and gets the details of your component from it: in particular, it gets the LP branch URL. It then downloads the ubuntu_component_store/bin and/or ubuntu_component_store/qml folders from your LP branch and puts them somewhere appropriate in the current project folder so that they’ll work and can be referenced from your code.
ucs search <something> searches community_components.jsonlocally.
This different approach means that the server is stateless; when it receives a ucs submit request, it updates the big metadata file with the new details, but the server is not part of the normal app developer process; it’s only used by component developers, and only for submissions. This makes the server much, much easier to write.