OneConf in Natty
Now that OneConf has been released in maverick, it's time to enhance it. This discussion is about what can be done for OneConf in Natty.
OneConf to get further than in maverick: installed by default, proposing reinstalling a computer package set from ubiquity, software-center integration polish and take the same credential than u1preferences.
If desktopcouch is removed from the CD, some magic in ubiquity to install it when needed.
update to new USC API: DONE
[nataliabidart] provide dbus method for ubuntu-sso-client so that a set of credentials can be stored: DONE
Work items (ubuntu-
[chipaca] compressing desktopcouch by default: POSTPONED
-- postponed to O:
The POR of tuesday's desktop team meeting is that OneConf will move next cycle to software-center infrastructure and there won't be a migration path from couchdb to software-center. So, rather than spending time this cycle to set OneConf as default, we will just try to get it working in natty (software-center port is done, still need new u1 sso port) with some small enhancement. The work on porting oneconf to the new infra will be done for O and then, we can reconsider it by default.
using same id than u1 preferences dialog: TODO
Creating an ubiquity window: TODO
figure out how to get xapian metadata as what is an application and what are the technical items: TODO
Being able to point to the couchdb u1 server for install time: TODO
Using u1 sso new call in ubiquity and enable copying it to the target system: TODO
Enabling creation of a manifest file: TODO
Add wallpaper support: TODO
update oneconf MIR and seed by default: TODO
integrating with u1 SSO: TODO
OneConf is currently integrated with USC, relying on desktopcouch. There is the issue of scalibity:
- improvment to desktopcouch? (a lot of data filing in)
-> refactoring of desktopcouch will be done soon
- real deletion to the DB
The current design isn't the mpt one:
- how can we get a complex tree from USC?
-> postpone for natty
- having a touch approach?
- how can we remove/hide selection from another computer (like, you reinstalled it, need a GUI for that)
- we can know the cause of the difference between two computers, like "never installed on remote computer", or "as beeing removed at…" or "installed on…"
What can we do with the data we have?
- additional ppa?
-> available in the detail view, enabling the ppa from there
- ordering by installation date
- sharing a list of applications/bundle
-> creating a manifest file for that.
- being able to push temporary directly to desktopcouch in the u1 db so that you can access to it anywhere (signing temporary to your u1 account). Making a website.
Use Ubuntu sso
Some enhance performance trick, especially on netbook.
Get and update the wallpaper of the recorded host
use the wallpaper icon to associate with the computer.
Integration in ubiquity ?
-> sso authentifcation at start
-> can't wait for desktopcouch to sync, how to get the data ?
We can use the API to directly point the server.
We don't want to popup an additionnal dialog.
- Why do we need to distinguish between user-facing apps and libs ("technical items") here? just for displaying what gets synced? USC already does that, we should just use the same algorithm for this for consistency.
- I don't quite get why a system-level problem (package list) is handled on a per-user session database (desktopcouch). What kind of data would we need to put into desktopcouch? Also, isn't this quite a lot of overhead for ubiquity integration & co? Can't we just use regular file sync for the package list? (Note that we might drop couchdb/erlang from the CDs if we run low on space).
- What is a manifest file? How does it differ from dpkg --get-selections?
- We don't want to display what get synced. just a way to tell "install all my applications as *this* computer (*this* beeing selected in a dropdown box). The algorithm is made by tag in Xapian database, hence the "figure out how to get xapian metadata as what is an application and what are the technical items: TODO" WI.
- the thing is that we want to duplicate this entry between computers on ubuntu one, it's the goal of oneconf. However, there is no way right now for u1 couchdb to be synced on a system-level, only user-level is possible. I just deal with that. There is no way to get only one file with all the deps in the live session (it's "you sync everything or nothing"). I don't think I have 50 Go of RAM space for it and want to wait for it during ubiquity installation. :)
So, the plan discussed in the session was : point to ubuntuone server couchdb (not asking for synchronisation) directly in the live session. If you are really about to remove desktopcouch from the CD, we will have to install it (in any case, oneconf ubiquity panel will only appear if you have a working internet connexion) as we install mp3 and langpack.
- the manifest file is an export of a plain text file of relevant installed package (filtering auto-installed package and telling for each package if it's an application or a technical item)
- I thought U1 would allow syncing several different directories; so this doesn't work independently?; however, now you would have the problem that it might sync many GB of couchdb data -- after all, that's the preferred storage for tomboy notes, evo addresses, and all quickly apps; can couchdb just sync a part of its tree?
- U1 can synced multiple directory, but not cherry-picked independently. (you can't say "I don't want that directory there"). It's basically "nothing or everything".
It seems I wasn't clear previously, we don't need to sync couchdb in the live session as we can directly point to the ubuntuone server couchdb (the master one) and so, avoid getting all this sync mechanism in the live session itself. Just retrieving relevant data remotely.
- setting as pending approval again