On Mon, Jul 01, 2013 at 05:32:41PM +0100, Dave Morley wrote: > 1. The click search will be done by an online backend?
Yes. > 2. How do you search for useful .deb armhf apps if there is no apt db? The client code should (at least be able to, for convergence) talk to an abstraction layer that looks at both the apt database and the click online service. Whether that will be enabled on the phone I don't know, since I gather Xapian is a bit of a problem. > 3. If there is going to be a apt db then why not add the click package > listing there too Putting click packages in the apt database would bring back the scaling limitations that are a large part of the reason we're doing a separate packaging format in the first place. > 4. For armhf apps and click apps You mean "deb apps" or some such - deb/click is a different axis from armhf/i386/any-other-architecture. Click packages may contain binaries and/or libraries compiled for the armhf architecture. > will there be an entry added on apps.ubuntu.com/cat which has > primarily stored .debs to date. Don't know. > 5. Primary install will be carried out via dash what happens if an > install fails (currently you are presented with an alternate method > via your purchase email) If the download succeeds, installation failures should be much rarer with click, but they're still possible (e.g. out of disk, I/O errors, etc.). We'll still need a way to deal with those. > 6. Documentation/Documentation/Documentation we need some very good > docs taking a standard app process from start to finish, these need to > be easy enough to understand that anyone can use the sdk and build a > click app and publish it. But also cover devs who are not using the > sdk to create and build from. > The dev needs to know what the review will entail. You've mentioned review in a couple of recent mails. Another significant point of click package is that manual review shouldn't be necessary; we already know it doesn't scale. If it is necessary, then it'll have to be very significantly scaled back. > What is an isn't acceptable in a package. (preferably added to a tos, > as well a link in the application upload page) I think somebody had a ToS on their to-do list; it came up in the context of name clashes. -- Colin Watson [[email protected]] -- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
