=== mr_ian_ is now known as mr_ian
jMylesHey everybody.02:06
ddoom_is there a cli for ubuntu one?04:52
=== mr_ian_ is now known as mr_ian
=== CardinalXiminez_ is now known as CardinalFang
=== aquarius is now known as jono
=== jono is now known as aquarius
urbanapeMorning, folks.14:13
aquariushey urbanape14:17
urbanapesmells like standup15:00
urbanape*sniff sniff* yup15:00
dobeythat's just the teen spirit15:00
urbanapeah, basically the same thing15:00
* urbanape slouches15:00
urbanapeMEETING BEGINS AND/OR STARTS! Desktop+ crowd, say "me" to get your turn for DONE/TODO/PLANNING/BLOCK15:03
urbanapeaquarius, jblount, Chipaca?15:05
urbanape(I forget who else, so forgive)15:05
urbanapeDONE: Separated out the lazr-js/YUI 3 from the new behavior and proposed the former for review. Will propose the latter shortly.15:06
urbanapeTODO: Get Bindwood into SRU pipeline, so people don't have to rely on the PPA build.15:06
urbanapePLANNING: Bindwood improvements (manifest, threading, proper delete handling, &c)15:06
urbanapeBLOCK: None15:06
urbanapeCardinalFang: The COMFY CHAIR!15:06
dobeywait, what15:06
CardinalFangDONE: Found cause of Bug#475447, and assigned to python-gobject.  Landed attachments (yay).  Made list of things to fix in desktopcouch.15:06
CardinalFangTODO: Fix minor d-c bug 445611 ("expose revision in Record").  Release desktopcouch 0.6.  Upload to Lucid.15:06
CardinalFangBLOCKED: None15:06
CardinalFangteknico!  It's a fair cop.15:06
ubottuLaunchpad bug 445611 in desktopcouch "The Record class should expose the current record revision" [Medium,Triaged] https://launchpad.net/bugs/44561115:06
dobeywhat is this PLANNING thling?15:06
teknicoDONE: more reviews, funambol presentation, discussed timestamps code for Funambol with thisfred and vds (#399200), started work on disabling free phone sync after 30 days (#403941)15:06
teknicoTODO: more planning with Chipaca and vds, finish disabling free phone sync after 30 days (#403941)15:06
teknicoBLOCK: none15:06
tekniconext: vds15:06
vdsDONE: did the review with a lot of people from the team, investigated on 30 days free plan, found problems with sync, triaged with thisfred, triaged problems with simplejson, discussing bout 30 free plan15:06
vdsTODO: check the sync works after the fixes, go ahead with the 30 free plans15:06
vdsBLOCKED: nope15:06
vdsrodrigo_: please15:06
urbanapedobey: Chipaca asked for it yesterday15:07
rodrigo_• DONE: XML<->HTML fixes. Face and review duty15:07
rodrigo_• TODO: Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine?15:07
rodrigo_• PLANNING: contacts picker, music store, XML<->HTML move to lxml15:07
rodrigo_• BLOCKED: no15:07
rodrigo_next: dobey15:07
dobey☺ DONE: Chat with John Lea about some issues in new client app spec, Triage, Client backports15:07
dobey☹ TODO: Planning, Verify client backports and bugs, 1.0.3 client release, SRU packages15:07
dobey☹ BLCK: None.15:07
dobeyaquarius: roll15:07
urbanapeI'm not sure how it differs from TODO15:07
aquarius⚀ DONE: work out how music store stuff all fits together; planning homework15:07
aquarius⚁ TODO: make tomboy first-sync experience nicer; continue work on desktopcouch developer docs; write up things learned at UDS/sprint; work with rodrigo on Music Store, some more music store architecture planning; step-by-step guide to what happens during contact sync; write "pipe" to transfer data between two HTTP connections with twisted 9.0; write lazr-js branch15:07
aquarius⚂ BLOCKED: music partner15:07
rodrigo_urbanape: yeah :)15:07
dobeyurbanape: no, he wanted us to do the planning he sent e-mail asking us to do last week... "put it in your TODO to do that planning" :)15:08
urbanapeah, my misread15:08
dobeyaquarius: i think Chipaca is next15:08
urbanapenm, then15:08
aquariusah, soz, Chipaca, go for it15:08
ChipacaDONE: hit people on the head re planning. TODO: continue hitting people on the head re planning, and get planning done. BLOCKED: no, except by people whose heads are harder than I can hit15:08
* rodrigo_ gets his helmet15:09
rodrigo_Chipaca: so, the planning thing, I understood last week that you wanted a planning for the week, is that so?15:09
* urbanape is insensate in the head area, he assumes.15:09
Chipacarodrigo_: for the week, every week. I also need a release plan, but that is different (and I have most of those parts)15:10
rodrigo_Chipaca: and should we send it to you at the beginning of each week?15:10
urbanapeaha, it all makes sorta sense now.15:10
Chipacayour day on monday should start something like: read email, ingest caffeine, read friends blogs, do planning15:11
aquariuswe're supposed to email it to you?15:11
aquariusI must have missed that bit15:11
Chipacano, you're supposed to create branches for the work you'll be doing15:11
aquariusah, good.15:11
Chipacaempty branches, to be filled in when you actually do it15:11
aquariusdid that. ;)15:11
Chipacaaquarius: is your launchpad user "sil"?15:12
urbanapeI missed the original meeting on 30 Nov. and the one that presumably happened this past Monday.15:12
aquariusChipaca, yep15:12
dobeybranches don't correlate with 99% of the work i've done this week15:12
aquariusnor me, really, but one does, so it got a branch15:12
CardinalFangChipaca, what about researching bugs?  E.g., my #475447, "Ubuntu-One client/syncd cause 10 wake ups / second each".  That took some time to figure out if it's legitimate and whose problem it was, and it didn't need a branch or work from me this time.15:14
Chipacadobey: I thought you prepared SRUs in launchpad?15:14
ChipacaCardinalFang: could you have planned for that at the start of the week?15:15
Chipacain any case, I'm open to suggestions as to how to plan with minimal overhead15:15
dobeyChipaca: there are revisions from trunk that i backported to stable, but that's just a matter of finding the revision that fixed the bugs we need to get fixed in the SRU (for those that have been fixed already)15:15
dobeybzr merge -c REVNO ../trunk; bzr commit --author "Original Author" is all the "branch work" really15:16
CardinalFangChipaca, I could have made a branch, but there was no way of knowing that I'd follow it from our apps -> twisted -> gobject -> pygtk source.15:16
dobeywhich is all insignificant as far as time goes15:16
dobeymost of the work is searching through LP for the bugs, and matching them up with the revisions in trunk that fixed them. making sure the bugs are targetted properly, etc...15:17
dobeythen i just gotta make a release of client today and do the SRU packaging, and submit it to get uploaded to karmic15:17
CardinalFangthisfred, aquarius, I'm adding a getter property for d-c Record for record revision.  This should be read-only, right?  There's never a good reason to set the _rev on something, right?15:18
aquariusCardinalFang, correct.15:18
dobeybut hopefully i can start working on the new client bits15:19
aquariusCardinalFang, if someone wants to explicitly do that then they can do it the hard way. :)15:19
Chipacarodrigo_: CardinalFang: dobey: re the different bits you're working on that are not new features, would one day a week (more or less) be enough to cover that?15:22
rodrigo_Chipaca: yes, but sometimes a branch needs a previous one, and it takes more than one day to get them approved, but generally yes15:24
Chipacarodrigo_: waiting for a branch to be approved shouldn't be busy time :)15:25
dobeyChipaca: not really. at least not yet. maybe after this initial SRU hump, that will be fine.15:25
dobeyrodrigo_: you can specify a branch needs another one when proposing now, btw15:25
rodrigo_Chipaca: it is, at least for the contacts picker, which I guess is 'new features' though :)15:25
rodrigo_dobey: ah, ok15:26
dobeyrodrigo_: but waiting for review shouldn't block development15:26
CardinalFangaquarius, thisfred, https://code.edge.launchpad.net/~cmiller/desktopcouch/record-expose-revid-bug445611/+merge/1595315:26
dobeythough i really wish i could spend some time working on infrastructure15:26
thisfredCardinalFang: might not have time to look at it any time soon. Maybe after lunchish15:27
CardinalFangthisfred, okay.  it's v small, fwiw.15:27
aquariusCardinalFang, a bit worried about record_revision.startswith("1-") -- can we depend on the couch people not changing that/15:27
Chipacadobey: I'll ping you later to talk about that15:28
Chipacadobey: most infrastructure work is best passed on to other people to do :)15:28
aquariusI asked last week whether we can guarantee that revisions go 1-xxx, 2-yyy, 3-zzz, etc, and no-one was prepared to say yes :)15:28
thisfredCardinalFang: right. This is a very leaky abstraction. I though the whole point was we didn't want to expose couchdb internals15:28
thisfredCardinalFang: and if people do want to get at them, ._rev seems fair warning15:29
thisfredaquarius: I think they don't, especially in the face of conflict resolution15:29
Chipacaok, bbiab15:29
CardinalFangaquarius, no.  It could start with "0" next week.  It's just a sanity test, not part of the code.15:29
CardinalFangI do want to test that it's something I get from the DB.15:30
aquariusCardinalFang, yeah, but if they change couch they'll break that test, and we're not relying on 1-* as the first revision, which means that we've got a test that tells us that couch has changed but there's no benefit to it15:30
CardinalFangThe only guarantee I have is that a subsequent revision id would lexically sort later.15:30
dobeyChipaca: ok15:31
aquariusif it was protecting us because elsewhere we rely on that behaviour, it's certainly a good thing to test, but it feels a bit like we're just setting up to get a broken test there :)15:31
aquariusor is that test really saying "is this record stored to the DB"?15:31
CardinalFangaquarius, so, another put, get, test for greater-than.  That would make me somewhat more sure that the value came from the DB.  Would it make you happy?15:32
aquariuswhat I'm wondering is: "is this record from the DB" is a useful question to ask; should we have an explicit way of answering it, rather than something sorta subsidiary like "does it have a revno"?15:32
aquariusor am I misunderstanding the point of your test?15:32
thisfredI would think the testing for is not None would be enough15:33
CardinalFangI want to make sure it's something the user should expect and find useful.  I test not-None, but I want something better.15:33
aquariussorry, I know I'm bikeshedding here15:34
thisfredI still think it should be underscored, so as to warn API consumers from relying on any specifics.15:35
CardinalFangaquarius, how is that now?15:37
aquariusCardinalFang, nice, that looks good15:39
aquariuswill test15:39
CardinalFangthisfred, okay, your complaint is that the very idea of revision id is too much internal knowledge of couchdb?15:44
thisfredyes. I can see where it may be useful sometimes, but an _ method/property makes it clear it is not part of our API and subject to change at any time15:45
thisfredthat is an opinion though, so if I'm outvoted I can live with that and will approve the branch15:46
urbanapeI don't see how you can test for something being a CouchDB-related thing without having some internal knowledge of its state or representation15:46
CardinalFangthisfred, it's your bug.  aquarius any opinion?15:46
thisfredis it?eh which bug?15:47
thisfredthe branchname is  a clue15:47
aquariusthisfred, my opinion is: if we don't give people a way to get at that stuff, they'll just go around our API anyway. Knowing the revision number of something is useful (look at what you're doing with revnos elsewhere, for example)15:47
CardinalFangthisfred, ah, it was assigned to you.  I thought you reported it.15:47
thisfredaquarius: if it's in our API, we are responsible for it not changing dramatically15:48
aquariusthisfred, only sorta. I mean, we expose a revision number. We don't care what it is15:49
thisfredaquarius: right, but then what's the point? I'd rather expose something useful, like _changes. As chad already has15:49
thisfredaquarius: I forget what I'm using revnos for elsewhere15:50
aquariusthisfred, same reason you're using revnos on the server; to be able to say "this document I've got? is it different from last time?"15:50
thisfredaquarius: I don't think I do, much.15:50
thisfredI explicitly try to hide that from consumers, by having the update_fields method15:51
thisfredwhich behaves as if you update a single field in a document15:51
thisfredupdate_field, likely15:51
thisfredso you don't have to care about revnos15:51
thisfredIMO that's an omission in python-couchdb15:52
thisfredaquarius: actually, cloud_server does not use revision numbers anywhere, I don't think15:53
thisfredI just grepped15:53
thisfredthe watchdaemon does,15:53
thisfredbut I don't know why, I didn't write that15:53
thisfredit should probably use _changes15:53
aquariusI thought you were using revnos for phonesync tracking?15:54
thisfreddb sequence numbers15:54
urbanapeso, does this little exercise render the original bug Invald?15:54
thisfredwhich should also be deprecated in favor of _changes I think15:54
thisfredI don't know, teknico filed it15:55
aquariusyou can't deprecate seqnos in favour of _changes because you won't know what to put in "since"  :)15:55
thisfredmaybe the contacts web ui relies on revnos15:55
thisfredaquarius: why not?15:55
CardinalFangI have another complaint.  I mentioned it in the attachments branch.  To store attachments in Record and make CouchDatabase.put_record add them, I need the revision id to add them the piecemeal way.  for blob in blobs: put_attachment(container_id, container_revision, ...)  .15:55
CardinalFangSo my step is put, get the latest(!), attach, attach, attach.15:56
CardinalFangThat latest might not be what I just sent.15:56
thisfredaquarius: maybe I misunderstood that: we may have to still keep sequence numbers to query the _changes, but we would have a more efficient way to query for all the changes15:57
aquariusCardinalFang, yeah. How do you propose to resolve that, though?15:57
thisfredCardinalFang: I haven't done anything with attachments, but I gather they're not exactly a miracle of beauty in couchdb itself15:58
thisfredCardinalFang: can that be handled the same as the update_field method does? (I guess that should move to d-c since it doesn't have the same code as the cloud_server does)15:59
CardinalFangaquarius, I don't have a plan yet.  Perhaps petition couchdb to return the record_id and the revision.15:59
CardinalFang... on put15:59
rtgzRe: bug #479475 (my favorite bug these days). 1. Shared With Me directory should be translated into $HOME/.local/share/ubuntuone/shares on DBus request and remember the original path to update nautilus view (I have it done in Vala, much like readlink(1), need some Glib/C magic). 2. Since it is unlikely that SD will be rewritten to report status for a directory (bug #440848), I think the first step is to make ~/Ubuntu One emblems reflect current state, i.e. un16:00
rtgzsynchronized, synchronized, transferring. Q/C?16:00
ubottuLaunchpad bug 479475 in ubuntuone-client "File emblems don't display correct sync status" [Medium,Triaged] https://launchpad.net/bugs/47947516:00
ubottuLaunchpad bug 440848 in ubuntuone-client "UbuntuOne sync status emblems should apply to folders as well as files" [Wishlist,Triaged] https://launchpad.net/bugs/44084816:00
teknicothisfred, what original bug did I file?16:01
thisfredteknico:  #44561116:01
thisfredbug #44561116:02
ubottuLaunchpad bug 445611 in desktopcouch "The Record class should expose the current record revision" [Medium,Triaged] https://launchpad.net/bugs/44561116:02
urbanapeCardinalFang: that would be helpful for Bindwood, as well.16:03
urbanapewell, not so much, actually. I thought it could before and talked myself out of it then, too.16:03
teknicothisfred, right, I need it in the contacts web ui16:04
urbanapeI should go for a bike ride sometime today.16:04
thisfredCardinalFang: well, it seems all Client consumers disagree with me, so that would appear to be conclusive evidence ;)16:06
thisfredAPI consumers, I mean16:06
teknicothisfred, any suggestions of a different way to detect attemps to changing the same record revision?16:07
thisfredteknico: I don't know what that means? why would you wnat to detect attempts to change a revision?16:07
thisfredrevisions never change16:07
teknicothisfred, we talked about it :-) here's the sequence:16:07
thisfredI'll have a look at the code16:08
thisfred(I remember that we did, but not the specifics)16:08
teknico1) a user opens the contact editing form, thereby loading rev.116:08
teknico2) a sync changes the record, moving it to rev.216:08
teknico3) the user tries to save the changed rev.116:09
thisfredteknico: ah. Again this is better solved by using update_fields()16:09
teknico4) the server code notices rev.1 is not current anymore, denies the changes, and issues a conflict notice to the user16:09
thisfredwhich will update only the specified fields16:09
thisfredplaces a bit more burden on the webui, because the form there needs to keep track of which fields changed or did not, but then it will work16:10
aquariuscan't you just *try* and save the thing? couch will give you a conflict anyway16:11
teknicothisfred, that's exactly what the web ui code is16:11
teknico*not* doing now16:11
thisfredaquarius: not easily in python-couchdb16:11
aquariussounds like you're reinventing the couch conflict code, no?16:11
teknicobut that's not the problem16:11
teknicothe problem is, how do you know that the user is agreed with merging their changes with the ones coming from the sync?16:11
thisfredaquarius: no, I'm doing preemptive conflict resolution in the case you only update one or a few fields16:11
aquariusthisfred, that's not how you're supposed to do it ;)16:12
aquariusclever, mind :)16:12
teknicothe user was seeing some values, and they changed them accordingly16:13
thisfredteknico: yeah, you're right16:13
teknicoit does not seem good to end with something different from what the user thought it would16:13
thisfredteknico: well, you never end up with something different than the user intended, it's just that they might have intended something else if they had had more information...16:14
teknicothat's why I prefer to punt and have the user start again from the new, synced values16:14
teknicodiscarding the now obsolete user changes16:14
thisfredyes, it's better. But more annoying ;)16:14
thisfredYou don't know that they're obsolete16:14
teknicothisfred, yeah, I know, it's a fast world, who cares about quality, and all that16:15
teknicoI say: screw it! ;-)16:15
thisfredIn most case they won't be obsolete, I would bet16:15
teknicothisfred, the power of the ring is great, but you must resist it ;-)16:15
thisfredThey might be fixing a typo that someone else also fixed, in which case the changes will be identical (update fields is smart enough to not even write the change in that case)16:16
thisfredor the user might have a different opinion than the other updater, in which case letting their change win is optimal16:16
teknicothisfred, that's like having bazaar merge together a different, but almost identical line :-)16:17
thisfredaquarius: I should rename the function to force_update_fields, probably16:17
teknicothisfred, so it doesn't even fail when there are changes to the same fields?16:17
thisfredand put <blink> tags in the docstring16:17
thisfredteknico: it will never fail16:17
aquariusit does sound a bit less like "please update these, if nothing's changed" and a bit more like "YAAR! I AM RIGHT! YOU LOSE, OLD CHANGES! YAAAAR!"16:17
thisfredthe values the method tries to change will always win, any updates to other fields will be preserved16:18
teknicothisfred, is that function already in trunk? DID I REVIEW IT? oh, the horrors ;-P16:18
thisfredaquarius: you *only* lose updates to the fields you're changing, not to other fields16:18
thisfredI don't know if you reviewed it, but it has been in trunk for months16:19
aquariusthis is like saying "I have only pissed on *some* of your chips", I think. ;-)16:19
teknicothisfred, oh, ok, that function has no notion of some fields having being changed by something else16:19
aquariusI quite like teh cleverness of update_fields, though :)16:19
thisfredaquarius: well, only on the chips I meant to piss onb16:19
thisfredaquarius: I will rename it to force_update_fields, but then I think it could go into desktopcouch16:20
teknicoso, in my previous scenario, if the sync changed field A, and the user changed field A too, the user will not ever see the value of field A coming from the sync16:20
teknicothisfred, I don't see I that could possibly be good16:20
thisfredteknico: yes16:20
teknicoI don't see *how16:20
thisfredwell, I it's convenience over correctness16:20
thisfredI agree that storing a conflict document would be better16:21
teknicothisfred, it's MySQL over PostgreSQL :-(16:21
thisfredyou take that back!16:21
teknicothisfred, "storing a conflict document"?16:22
teknicohow would the user see that?16:22
thisfredbut I would like to store a conflict document with all the changes merged in, and have my version win16:22
thisfredteknico: that would be up to the ui16:22
thisfredyou just ask couch for the document with ?conflicts=true16:22
teknicothisfred, if I can show the user a summary of the situation with conflict values in evidence, that's so much better :-)16:23
thisfredand it will show you all conflicting versions16:23
thisfredI agree16:23
teknicothisfred, because you know how much love the user :-)16:23
teknicohow much *I love16:23
thisfredbut python-couchdb completely ignores this AFAIK16:23
teknicorecently I've seen talk of an async couchdb wrapper, what was it called?16:23
thisfredhey me too, I love them even more: I assume they know what they're doing and that they mean what they say ;)16:23
thisfredI don't know if couchdbkit does better, and if that's what you mean16:24
teknicothisfred, they can only do so if you don't hide stuff from them :-P16:24
thisfredteknico: yes16:25
teknicommm, no, it was Something Completely Different™16:25
thisfredso what I'd like optimally is: merge the changes to fields that don't conflict, and have the users changes for fields that do conflict win, *but* store the losing values in a conflict doc. then have the ui show the conflicting values16:26
thisfredI don't know if that is possible, or how I would do it16:26
teknicoI like it, except for the winning part16:27
thisfredteknico: well, one of the conflicting versions wins. That is couchdb16:27
thisfredteknico: unfortunately you have no control over which one16:28
thisfredor maybe that's good, in case both sets of changes came from my method ;)16:28
rtgzif (local && server && strcmp (local, server) == 0) { mark_as_synchronized }16:32
rtgzlocal = "", server = "", ... grrr16:32
* thisfred rethinks the method16:34
thisfredperhaps I should have it barf on changes to the same fields16:34
thisfredor store conflicts16:34
thisfredif I can from python-couchdb16:34
teknicothisfred, at least an option to *not* have it apply conflicting changes silently16:35
thisfredteknico: that's for wimps16:35
thisfredyeah you're right.16:35
thisfredI don't think the function is used all that much, to put everyone's mind at ease. I just had fun writing it ;)16:35
teknicothisfred, then it'll be even more fun fixin^Wchanging it! ;-)16:38
* dobey fixes up bugs for doing SRUs16:39
rtgzdobey, have you got to nautilus or not yet? In case no, then good - I have some additional comments (as always...)16:40
* rtgz hates that apt-get update erases his own little build of ubuntuone-client-gnome every time...16:41
dobeyfacundobatista: ping16:44
rtgzyup, the emblems got 'synchronized' for files immediately because the server hash and local hash matched perfectly when file was dropped into the directory: both were equal to empty string...16:45
thisfredteknico: I'll do this: if the merge of all changes succeeds, store it. if not, strore nothing return conflicting fields, with both values. Rename the method to try_update_fields.16:47
thisfredNo more silent anything, and no conflicts possible16:47
thisfredwildly ugly code and function behavior though16:48
rtgzcan anybody tell me what 'server_hash' means for directories?16:48
teknicothisfred, that's brilliant, consider yourself hugged ;-)16:48
thisfredteknico: it will mean work on the ui16:49
thisfredso don't hug too soon ;)16:49
teknicothe heavy lifting in that ugly code will beautify code elsewhere though :-)16:49
dobeyrtgz: it's the hash of the directory content, that the server knows16:49
teknicothisfred, at worst i can just punt like I do now ;-)16:49
thisfredand it's sort of unixy: return nothing in case of success16:50
rtgzdobey, okay, local_hash then?...16:50
thisfredbut not very pythonic16:50
dobeyrtgz: similar, but local version of it16:50
teknicoshowing the different values will require effort on the design side though16:50
rtgzdobey, :).. I mean if i put a file into the dir, then hash should be recalculated, I guess16:50
dobeyrtgz: empty local means it hasn't been hashed yet, empty server means it hasn't been created on the server yet16:50
teknicothisfred, when did python have something to say about return values? :-)16:50
rtgzdobey, the local hash i mean16:50
dobeyrtgz: yes16:50
thisfredteknico: just an extra row of text inputs, with <-> arrows, so you can ajax them around16:51
rtgzdobey, and if it does not then this is a bug report?16:51
dobeyrtgz: if it's not rehashing, it's probably not getting the inotify event or something, so yeah, it's a bug in syncdaemon perhaps (or possibly in inotify)16:51
dobeyrtgz: this sounds like the "syncdaemon not noticing new files" bug16:51
teknicothisfred, feel free to give advice to the design team, I just do what I'm told here ;-)16:52
dobeyrtgz: i've seen a few reports of that nature, but don't know a bug # off hand16:52
thisfredteknico: it's not very pythonic to have a method that does stuff, but if it fails returns something. An exception would be better. Can I return a  conflicts dictionary as part of the exception?16:52
rtgzdobey, syncdaemon has hashed the file but did not recalculate the directory info, Ok, will check that once more16:52
teknicothisfred, I think you can add custom attributes to an exception object, let me check16:52
dobeyrtgz: ok, that might be the problem then :)16:53
aquariusyou can16:53
thisfredthat's the way to go then16:54
aquariusclass UpdateConflictException(Exception): def __init__(self, brokenness): self.brokenness = brokenness16:54
aquariusand then people can get attributes of the exception when they catch it16:54
thisfredthanks all, for fixing my code! ;)16:55
thisfredaquarius: would you agree that this modified version of update_fields might have a place in d-c?16:55
aquariusyeah, I think it does. It's a useful API.16:55
aquariuswhat I'm not sure about is: should it be a completely separate way of working? surely every single access should work like this?16:56
thisfredok, I'll make a branch tonight, after I fix my other broken code ;)16:56
thisfredaquarius: eh yeah, I would use this everywhere on the server.16:56
thisfredaquarius: it might still be useful to have conflicts though: unattended processes can't resolve the conflicts, and it would suck if they could not write to the db16:58
thisfredlike sharing-sync16:58
aquariusit still *is* a conflict.16:58
thisfredaquarius: I mean, they would not have a good way to deal with the exception16:58
aquariusit is pretty much never right for you to say "save my changes" if something else has happened in the interim16:58
aquariusyou can avoid it by updating the record.16:59
thisfredaquarius: yeah that's what I'm doing now, but in the case the same field was changed, you need to pick a winner16:59
thisfredor store a conflict16:59
thisfredin the case where a user is driving, present the conflict to the ui, and have them picj17:00
aquariusI...think it's up to the app to pick a winner.17:00
aquariusif it's possible to do unattended, then let the app that writes second do it17:00
aquariusif it's not possible to do unattended, then don't run unattended17:00
aquariusstoring conflicts seems to me to not be the right thing to do; we just can't avoid it in a world with replication in it17:01
thisfredaquarius: I would say store conflicts documents on exceptions  when unattended17:01
aquariusI'm not convinced17:01
thisfredand then the user/app can resolve them later17:01
aquariusalso, can we?17:01
thisfredaquarius: we can, through http if need be17:01
aquariusisn't replication mildly magic? can we deliberately store a conflict?17:01
thisfredhmm, I thought you could17:02
thisfredbulk updates can17:02
thisfredor can't they?17:02
thisfredI will ask for input when I start coding17:03
thisfrednow my trunk is broken, because there is no _add_record method anymore17:03
thisfredthat's good though17:04
dobeylunch time17:19
Chipacateknico: ok, let's do this thing17:33
Chipacamandel: eh, hola!17:33
teknicoChipaca, it would be best to do it with vds too17:34
mandelChipaca, hola :D17:34
Chipacateknico: can you wait up that long?17:34
teknicoalso, I owe an answer to mandel since yesterday :-)17:34
Chipacateknico: the planning is so much easier when one of the people that has to do things is away!17:34
teknicoChipaca, yes, I'll be around17:34
Chipacateknico: ok :)17:34
teknicoChipaca, you're not getting away with that, you know ;-P17:35
mandelChipaca, I'll entertain him teknico if you need him to stay for a while ;)17:35
teknicomandel, thanks, but I don't really need him to *not* be elsewhere right now ;-)17:36
CardinalFangmandel, hi.  attachments branch is merged.17:37
mandelCardinalFang, awesome, as soon as I can I'll add avatars to the contacts, thanks A LOT17:38
CardinalFangmandel, de nada.  Tell me if it's not exactly obvious how to use it.17:39
mandelCardinalFang, will ask you, within the limits17:40
aquariusverterok, ping?17:40
teknicomandel, wow, bazaar is erroring out while trying to merge your branch :-/17:56
teknicomandel, no, wait, PEBKAC17:57
teknicoI'm too used to live in the server code :-)17:58
mandelteknico, hehe I've not heard PEBKAC in a long time17:58
teknicomandel, well, in this age of laptops, it reeks of viagra spam ;-)17:59
mandelteknico, you forget watches and university titles...18:01
teknicomandel, yes, I do, what about them? :-)18:02
mandelteknico, they go hand in hand with the viagra spam :P18:03
teknicomandel, no, I mentioned viagra in specific relation to the acronym, think about it ;-)18:05
mandelteknico, agg... you are to graphic for me hehe18:05
teknicomandel, can you please merge forward your branch?18:22
teknicoI see unrelated changes in it18:22
mandelteknico, waht do you mean?18:24
teknicomandel, it looks like there have been changes in desktopcouch trunk since you branched it18:24
teknicoyou should merge the current trunk into your branch18:25
teknicoso that its diff only contains you changes18:25
mandelok, I'll do, that is probably the merge from CardinalFang related to the attachments18:25
teknicoor am I missing something?18:25
teknicomandel, yes, I saw those18:25
mandelteknico, I'll update the branch, sorry I forgot to do it, give me a sec18:26
teknicomandel, sure, thanks18:26
mandelteknico, sorted18:27
rtgzdobey, how about adding 'Danger' emblem to u1conflict.* files?18:32
dobeybut they aren't dangerous18:32
dobeyand that emblem also doesn't make any sense18:32
dobeyand it's a separate file18:32
dobeybut i'm not sure what we should do in the file manager18:32
rtgzdobey, but they are neither non-synchronized nor synchronizable...18:32
rtgzdobey, right, not dangerous, but calling for attention, of some sort...18:33
rtgz'Oh no!' ...18:33
rtgzand .. 'Important'?18:34
dobeyif they do deserve an emblem, it should probably be some new thing18:35
dobeynot one of the broken things already in nautilus that really shouldn't be there anyway18:35
Chipacawhat does the nautilus bzr plugin do for conflicts?18:35
dobeywhat nautilus bzr plugin?18:35
rtgzChipaca, bzr plugin o_O ?18:36
rtgznot in ubuntu :(18:36
Chipacaverterok: ping :)18:37
ChipacaI think it's part of bzr-gtk18:37
Chipacajohnlea: ping you too :)18:39
rtgzI guess .u1partial deserves some icon as well18:39
teknicomandel, it looks like we need more discussion to evaluate your branch changes to desktopcouch18:40
rtgzOr at least it does not deserve the default 'sync/unsync' emblems18:40
mandelteknico,  ok, let me know18:40
dobeyrtgz: .u1partial files don't exist18:40
mandelteknico,  I've done my best to reduce the redundancy in contact details and make the tests better.simpler18:40
teknicomandel, yes, that's a marked improvement18:41
rtgzdobey, "I want to believe", yup, never seen them but they are documented on Wiki...18:41
teknicosome of my suggestions are not there yet, though ;-)18:41
mandelteknico, dammed, what did I forget!18:41
dobeyChipaca, rtgz: you have to manually copy /usr/share/pyshared/bzrlib/plugins/gtk/nautilus-bzr.py to the nautilus python plug-ins dir18:41
teknicohowever, I concentrated on the mechanics, while we need more clarity on the api level18:41
teknicothat's what we need to focus on now18:42
dobeymaybe that should be done in the package, and split to a nautilus-bzr package18:42
dobey(or bzr-nautilus)18:42
dobeyrtgz: the wiki is old :)18:42
mandelteknico, sure, let me know :)18:42
rtgzdobey, aaaaaaaaaa18:42
Chipacadobey: I've got bzr-gtk via "bzr co lp:bzr-gtk" in .bazaar/plugins :)18:42
dobeyChipaca: did you copy the nautilus-bzr.py file over to /usr/lib/nautilus/extensions-2.0/python/ ?18:43
Chipacadobey: nope (I'm not using the nautilus extension)18:43
dobeyChipaca: that's probably a bad idea, since bzr-gtk isn't only a plug-in :)18:43
dobeyor isn't only a bzr plug-in18:44
teknicomandel, I will18:44
teknicomandel, on a related subject, when can I start playing with macaco itself? :-)18:44
Chipacadobey: I obey verterok18:44
dobeybut anyway, it looks like you have to manually copy the nautilus extension over18:44
dobeyverterok: bad verterok :)18:44
dobeyof course it works, but probably not as useful as could be18:44
dobeyChipaca: do you actually use the g* commands in bzr?18:45
rtgzdobey, okay, don't see any conflict emblems - bzr-ignored, bzr-controlled, bzr-modified, bzr-added, bzr-removed...18:45
mandelteknico, well, I'm working on the groups support which I want to have for next week, then you are more than welcome18:45
Chipacadobey: yes, of course18:45
mandelteknico, and avatars since Chad added attachments support18:45
teknicomandel, oh right, that the other thing I saw you discussing18:45
dobeyChipaca: and the fact that they hold bzr locks doesn't bother the heck out of you? :)18:45
teknicowhat's with the dicts for groups/categories? I did not quite get that18:45
Chipacadobey: not in the least, no18:46
Chipacadobey: in fact I didn't know they did18:46
sandsmarkare there any plans to release the source code for the server side part? :-)18:47
rtgzdobey, yeah, right... bzr-conflict. The emblem exists, but it is not referenced from the script. Nice.18:47
dobeyChipaca: yep, they hold the lock on the branch. so you can't do bzr gdiff & and then do bzr st in the same branch :-/18:47
dobeysandsmark: no. but several pieces we use in the server are already open source :)18:48
rtgzdobey, but it does need some kind of emblem, It took a while to understand that my folder_with_long_name.u1conflict looks much different from folder_with_long_name18:48
mandelteknico, I was just asking how would the group sbe represented in the document18:48
sandsmarkdobey: heh, ok18:48
* sandsmark already has a server :-P18:48
sandsmark(as in the hardware and rackspace :-)18:48
mandelteknico, I believe aquarius and I were both thinking about doing it this way: http://pastebin.com/dd904c0a18:48
teknicomandel, mmm, right, the MergeableList thing18:50
mandelteknico, I initially found it quite confusing since if you have a list of lists desktopcouch will convert that in a MergeableList of MergeableLists, I don't mind the first, but the second mergeable list I find a bit over the top18:51
nperryHello guys, Hope somone can help me.18:52
teknicomandel, I don't see why two levels...?18:52
nperryI'm helping doing bugs at the moment and we seem to be having a lot of ubuntuone bugs in LP - What would you recommend to be enough information for us to triage the bug.18:53
dobeyhi nperry18:54
nperryHello dobey :)18:54
dobeynperry: they can be hard to triage... most of them are likely dups of bugs that I am about to push SRUs for :)18:54
teknicomandel, fyi, evolution keeps categories in one comma-separated text field18:55
mandelteknico, the record API will convert the following [["Rock", "AC/DC"]["Friends", "Rugby"]] in two dicts. aquarius recommended to stick with a list of lists because he must have some friend in AC/DC (that is allow any char in the name of the group)18:55
jblountnperry: https://wiki.ubuntu.com/UbuntuOne#Bug%20Triage has some details18:55
mandelteknico, although rodrigo_ and I where more up for the char separated idea18:55
teknicothat's one of the sticky points in the move to attribute names :-/18:55
aquariusmandel, you've gotta do nested mergeablelists. Weird, but true.18:56
teknicoanyway, back the point, I don't see the meaning18:56
teknicoaquarius, care to explain what that means?18:56
teknico"that" = "[["Rock", "AC/DC"]["Friends", "Rugby"]]"18:56
dobeynperry: if you have any questions or concerns about specific bugs, please ping and ask us though. hopefully I can plow through some of the bugs once I get these SRU builds finished.18:57
aquariusif you were setting up a list of categories that a contact was in, and you want to have nested categories, you'd instinctively think of storing it like this: ["Sports Club/Tennis", "Family"]18:58
aquariusif, for example, the contact was my brother, and he's also in my tennis group18:58
rtgzdobey, okay, is "Shared with Me" folder supposed to have correct emblems or that is something that is low priority?18:58
aquariusand I want to have Sports Club/Football for people in my football group18:58
aquariusbut I also want to know everyone who's in the sports club, whether tennis or football, yes?18:58
dobeyrtgz: not sure what you mean18:58
aquariusteknico, but...I don't like using / as a separator, since it screws you up if you want a group named "AC/DC"18:59
Chipacadobey: rtgz: wasn't there a wiki page somewhere to help with u1 bug triage?18:59
rtgzdobey, currently SD is being queried for "/home/rtg/Ubuntu One/Shared With Me/Sharename from Shareuser/file", but it has no info about that path18:59
mandelaquarius: unless the separator is an even number of chars "//"18:59
aquariusso, store a list of categories that a person is in as a set of nested lists: [ "Italians", "Twisted users", [ "Canonical", "Ubuntu One"] ] (for my record of you, for example :))19:00
aquariusmandel, why bother to write some complicated parser that cares about splitting up a string? Just store it as a list; that's what lists are for.19:00
* rtgz is not a native speaker for English and "triage" looks somehow like triple age, or tripod... 19:00
dobeyChipaca: maybe. i don't know. i don't traverse the wiki much19:00
nperrydobey & jblount : Thanks ever so much!19:00
dobeyrtgz: oh, because nautilus isn't giving us the expanded path apparently :(19:01
rtgzChipaca, do you mean the script that was used to detect issues on the client side?19:01
Chipacartgz: yes19:01
jblountnperry: Thank you! I love it when people triage bugs.19:01
mandelaquarius: I'm just being annoying ;) (dejabu from UDS, reception hall + coffee + arguing about groups)19:01
rtgzdobey, yes, it does not, therefore additional link resolution is required19:01
rtgznperry, something like this https://wiki.ubuntu.com/RomanYepishev/UbuntuOne/Diagnostics might help19:02
* rtgz really needs to find out what "triage" means...19:02
dobey the process of sorting victims, as of a battle or disaster, to determine medical priority in order to increase the number of survivors.19:04
rtgzdobey, yes, the process of sorting, don't see how a script helps to sort the victims...19:05
urbanapertgz: incidentally, triage is of French origin19:06
teknicoback, sorry19:06
dobeymandel: i like arguing about groups! :)19:06
teknicoaquarius, I must have missed the memo about *nested* categories :-/19:07
dobeyrtgz: well, victims == bugtasks. some are more important than others, and some are faster to fix than others.19:07
teknicoeven given that we want them (and I'm not sure about it)19:07
mandeldobey, I remember hehe we just miss rodrigo_19:08
dobeyrtgz: it's sometimes hard for a script to determine those factors, but it's easy to determine if two issues in the tracker are due to the same problem19:08
aquariusteknico, yeah, it seems reasonable to do them, since if we don't, people will just try and emulate them by naming their groups "Friends/People I have not slept with" or whatever19:08
teknicohow do we reconcile them with evolution not supporting them?19:08
* aquarius waves hands about in the air vaguely19:08
teknicoehi, you really thought this through, didn't you? ;-D19:09
aquariusI have thoughts of a few ways: obvious way is to display group memberships on a contact in Evo but don't make it editable.19:09
dobeyevolution does groups19:09
dobeyin the exact same way that outlook does groups :)19:09
aquariusTwo better ways: 1. actually model groups as a separate record, which is useful if you want to share a whole group with someone or share to a group, etc19:09
teknicoevolution does *categories*, and flat at that19:10
aquarius2. make evo support groups.19:10
aquarius2 is best but hardest. :)19:10
dobeyit's not the best19:10
dobeybut i have a certain amount of want for replacing evolution with purpose-built applications :)19:10
mandeldobye, which way?19:10
teknicobtw, I like "categories" more than "groups", because "groups" sound more exclusive19:11
aquariusdobey, that's, like, the long-term goal here, I admit it :)19:11
mandeldobye, I mean does evo do groups19:11
dobeymandel: categories19:11
mandeldobye, aquarius, am I included on that (purpose-built applications) ;)19:11
aquariusteknico, but people think of things as groups. "I'm going out tonight with my theatre group", not "I'm going out tonight with the people in my 'theatre' addressbook category"19:11
teknicoas in, a contact only "belonging" to a group19:11
aquariusmandel, hell yes :P19:11
mandeldobye, ahh well that I knew ;)19:12
dobeyteknico: group is just another name for the same result19:12
dobeyteknico: which is that you are categorizing your contacts in some way19:12
teknicoI'm focusing on the ability of having the same contact in more than one group/category/whatever19:13
teknicowhich luckily is present in evolution19:13
mandelteknico, but that is easy right? you can have a contact in more than one category19:14
teknicoand useful at least to me, if not to the general "people"19:14
aquariusteknico, that's why it's stored as a list of lists; each "category" is a list, and the list of categories a contact is in is itself a list.19:16
teknicoI'm trying to make up my mind whether nested groups (ok, ok) are generally useful19:16
teknicoI can see the usefulness in a blog or cms19:16
mandelteknico, you might be able to create a view that returns all the groups and with those you generate the categories following some kind of rule Friends-Rugby for subgroup friends, and finding such a categories implies the existence of Friends19:16
aquariuswe had half-a-dozen use-cases for them at UDS. johnlea, ping abotu that/19:16
teknicofor contacts, it somewhat smells of geeky overkill :-)19:17
teknicooh, ok, is it recorded somewhere?19:17
mandelteknico, you would be amazed on how people organize their contacts with groups19:17
aquariusteknico, it doesn't have to be used, much. But think of a different display mechanism for your addressbook; not a list of contacts like in Evo, but something more like Nautilus, where each person gets a little icon19:18
aquariusteknico, which gives you a new way of interacting with contacts; drag a contact onto a file to share that file with that contact, etc19:18
verterokChipaca: pong19:18
aquariusgroups, in that example, would be like folders19:18
teknicowith hardlinks, hopefully ;-)19:19
aquariusif you drag one folder into another folder you can either (a) support that [and that's nested groups], or (b) pop up a dialog saying "you can't put one group inside another, get stuffed", which is actively user-hostile for no reason :)19:19
teknicoimplementation simplicity *is* reason, whether good or bad :-)19:20
mandelteknico, aquarius,  which is the new UI I have been working on and rodrigo_19:20
teknicoso, I guess all this is being reflected in mockups somewhere? or at least written down?19:21
mandelteknico, aquarius, I'm more worried on how do you represent the storing of a group. Do you store the Group and update all the contacts or assuming a group is not stored unless there are contacts in it? I can think of people filling bugs saying that empty groups disappear from the UI19:21
mandelteknico, first mockup I did is in lp:macaco, you can give it a go, but has no groups19:22
aquariusthat's why I also mentioned Alternative Option Number 1, which is that groups are a separate record.19:22
rtgzmandel, I would file such bug, for sure :)19:22
mandelrtgs, dammed I knew there would be at least one.... I hate u ;)19:23
teknicomandel, don't hate the user, you end up hating yourself ;-)19:24
mandelteknico, is that in the zen of programming? hehe19:25
Chipacaverterok: never mind, was re bzr nautilus thing19:26
mandelaquarius, anyway,getting back to it, so if there are no contacts in a group, there is no group? that is weird 'cause a would expect the same behavior as with an empty dir19:26
aquariusmandel, then groups have to be a separate record.19:26
mandelaquarius, if you want to support them as a dir I think it is the only sane way to do it, and let evo ignore them...19:27
dobeywouldn't a group with no contacts just be an empty list?19:28
teknicosigh, I liked evolution's simple approach, even if a bit "dirty"19:28
mandeldobey, no, since the list is in the record of the contact. If not contact points to the group, there is no group19:28
mandeldobey, kinda like if a tree falls in a forest and no one... blah blah19:29
verterokChipaca: oh, ok...I'm a qt guy19:29
aquariusdobey, if groups are stored as an attribute on a contact, you can't have an empty group 'cos there's nowhere to store its existence19:29
Chipacaverterok: ah19:30
dobeymandel: i thought i understood it would be a two-way association. creating a group creates a new record that is a list of contacts, and those contacts all have a list of which groups they are in19:30
Chipacaverterok: does that mean I have to hate you?19:30
verterokChipaca: at all :)19:30
Chipacaverterok: phew19:30
verterokChipaca: soon qt will be everywere ;)19:30
dobeyaquarius: it probably needs to be a separate record anyway, since there may be metadata to set on that "group"19:31
aquariusdobey, that's why I don't like groups as a separate record, because you have to keep the two in sync19:31
mandeldobey, like a double linked list?19:31
dobeyaquarius: for example, in evo, you can specify an icon for a category19:31
* urbanape resists falling into discussions of taxonomies19:31
aquariusdobey, yeah; you want to be able to do things like share a group with someone. I wrote up a load of stuff about this months ago, thinking about it19:31
dobeyaquarius: well, the sync bit should be trivial, since the lists should just contain the UIDs or whatever, no? :)19:32
aquariusurbanape, yeah, this is a KISS thing; I'm not modelling really complex stuff :)19:32
mandelaquarius, yes, but then subdir are not that nice to do19:32
aquariusdobey, it's not *hard*, I just don't like changes where you have to write the same thing twice in two places.19:32
urbanapeaquarius: even simple taxonomies have to answer hard questions19:33
dobeyaquarius: eh, twice is nothing19:33
urbanapeit's 100% more than once.19:33
dobeyaquarius: you haven't even considered that we might need to keep such things in sync across multiple social networking sites too :)19:33
mandeldobey, but with a sub-group of a sub-group etc.. pain in the ass19:33
aquariusmy point exactly :)19:33
dobeymandel: sub-groups are the slippery slope down the spiral19:33
aquariusdobey, I have considered it, and it's irritating but true. That sort of sync can be done asynchronously, though.19:34
aquariussubgroups are easy enough; as you said, we're just storing a list of IDs.19:34
dobeywell, desktopcouch doesn't need to care about facebook/etc...19:34
dobeythat's more the realm of central-services :)19:34
aquariusno, exactly.19:34
dobeyyes, in the model sub-groups is easy19:35
dobeybut they make the UI 10x worse19:35
mandelaquarius, they are easy to represent (subgroups), yes, but you will have be very lazy when implementing groups in the apps making it very chatty with desktopcouch  and I just like chatty in IRC...19:35
aquariusmandel, that's why there's a contacts abstraction layer amirite? so applications don't have to think about that. :)19:36
aquariusthis is what bulk updates are for, incidentally.19:36
mandelaquarius, dammed, I got bitten in the ass by my one stuff, good answer though ;)19:36
teknicoyes, the UI is going to be a bear, unless...19:38
teknico...unless we use trees, and I hope those are not going to cost us multiple associations19:39
teknicohence hardlinks :-)19:39
aquariuswhy will the UI be hard?19:39
dobeyhow do you avoid circular groups?19:39
mandeldobey, a group should have a unique path19:40
dobeybut if i have group id A and group id B, and i say B is a sub-group of A, can i also not say A is a subgroup of B?19:40
mandeldobey, so it is easy to find the error,19:40
aquariusdobey, same way you do it with folders; you prevent that explicitly.19:41
dobeymandel: the groups themselves would have their paths be /A and /B no?19:41
mandeldobey, aquarius, can't we use the path to the group as its id? there is nothing technically avoiding that, right?19:42
aquariusmandel, you can't do that, because if you rename a group then you have to edit every contact in it, because contacts link to their group by ID19:42
aquariusthat's doable, but daft :)19:42
mandelid of group A "_id":A ofsub group B "_id":"AB" or something of the kind19:43
mandelaquarius, are we in the page of using a diff record for groups, right? so why letting the contact know in which group he is19:44
mandelContact: that is external to him, someone place me there, ok, do I care? can I do something about it?19:44
aquariusit's possible to just have groups know about people and not have people know about groups. I'm fine with that, myself.19:44
* dobey would be happy just not having sub-groups19:45
dobeythey increase complexity for little/no gain19:45
mandelaquarius, two way links are harder to deal with and in this case do not add anything to the user19:45
aquariusthey don't increase complexity much.19:45
statikwho what? are we having groups as objects rather than just tags on contacts?19:46
mandelI agree there is not more complexity19:46
aquariusand people will just fake them if we don't provide them: a group called "Canonical/Ubuntu One" with all you guys in it.19:46
teknicoI agree with dobey, not sure about this tradeoff19:46
aquariusstatik, that's the conclusion we're coming to.19:46
mandelteknico, initially file systems just had one level, and know....19:46
dobeywell i don't think groups are the right way to deal with managerial hierarchy :)19:47
teknicomandel, I have 300k files from packages only, on this machines19:47
teknicothat's about three orders of magnitude more :-)19:48
teknicothan contacts19:48
mandelteknico, what I mean is that most normal people cannot deal with a huge amount of data19:48
statikaquarius, can you catch me up on why having groups as first class objects instead of just using a tagging system?19:48
mandelaverage people can only remember 10 items in short memory19:48
aquariusdobey, I'm not thinking of it being done that way for management. I have a legitimate use case for wanting to see (a) who I know at Canonical and (b) who I know in the Ubuntu One team, and I shouldn't have to explicitly put someone in both groups19:49
teknicosure, groups are useful, but I'not sure *nested* groups warrant the added complexity19:49
aquariusstatik, big problem with tags: you can't have an empty group.19:49
urbanapeboolean searches against single groups accomplishes the same thing19:49
urbanapeCanonical AND UbuntuOne19:49
urbanapeCommunity AND UbuntuOne19:49
aquariusurbanape, you join, I have to explicitly put you in both groups. That's stupid. The "Canonical" grouping is quite clearly a group of groups, not a group in its own right.19:49
mandelurbanape, you get back to the problem of empty groups19:50
aquariusstatik, second issue (which is smaller): you can't share a group if it's not an independent entity19:50
mandelurbanape, people will complain a lot if the groups disappear because there is no tag about it19:51
urbanapeaquarius: and do you duplicate that taxonomy to put rtgz somewhere? He's not a Canonical employee (unless I missed a note somewhere)19:51
urbanapebut he's a contributor19:51
urbanapemandel: not if it's termed tags19:51
mandelcontributors are lame... hehe (including me)19:51
urbanapeno one gripes when they remove the last of their tags off a photo on Flickr19:51
aquariusurbanape, yeah, that's the issue with a hierarchy. That's not modellable visually in any kind of sane way, though.19:52
urbanapetags are extremely easy to apply and remote19:52
mandelurbanape, but they do if you are using a dir metaphor19:52
urbanapegroups by definition are less ephemeral and are more boxey.19:52
aquariusthere's no reason why it can't be presented as tags in the UI, if you like that metaphor.19:52
mandelwait, I empty my dir of movies and the dir is not more there? WTF?19:52
urbanapepeople aren't movies19:52
teknicoI don't think the filesystem metaphor will take us far19:53
urbanapedamnit, I was hoping to resist getting invovled. I should just go hack bindwood.19:53
aquariusempty things disappearing breaks the user experience. I move home and I drag my previous flatmates out of the "Flatmates" group, before dragging the new people into the "Flatmates" group, and...pow, the Flatmates group disappears.19:53
mandelurbanape, the problem is the choice of metaphor, where you can work with contacts as you do in a file system19:53
teknicocontainment and exclusivity are tough to fight19:53
aquariusso I'm not able to drag the new ones in.19:53
aquariusIt's also not completely clear how you *create* a group, if we're using a visual metaphor like Nautilus.19:54
aquarius(and empty groups can't exist)19:54
mandelright click, new group => pow, not there is not people in it I have to remove it19:55
aquariusif the underlying implementation is groups-are-independent-entities it can be presented in UI as groups or as tags. If the underlying implementation is groups-are-tags-on-contacts then you can *only* present the visual metaphor as tagging, not as a folder/file hierarchy.19:55
aquariusstatik, that's my summary, coupled with a(n attempted) rebuttal of urbanape's points19:56
statikthis is very interesting19:56
statiki've just been playing with groups in google contacts and the snow leopard address book19:57
dobeyi do think you've oversimplified that case a bit though19:57
statiki don't see a problem with having an index of tags, so that you have something to keep the empty group alive, and maybe a couple of special virtual things like "contacts which are not tagged with any group"19:58
aquariusthat's a horrible, horrible bodge.19:58
aquariusbecause then if you want "the list of groups" you have to look in two places19:59
statikthe code would, yeah19:59
aquariusthis whole discussion boils down to, essentially, two questions: can a group with no members exist, and can a group contain groups as well as people?20:00
aquariuswe need firm answers on those, because those answers dictate the model.20:00
mandelaqurius, well, with a view you could query all docs with a categories field and you can create a special doc with all the empty groups in. When calling the view you get all groups easily20:01
aquariusI think the answers are yes, and yes, which basically means that the model needs to maintain a group as a separate entity from a person, or have a load of strange work-around bodges.20:01
aquariusif you think the answers are no and no, then tags on a contact is a fine way of modelling them20:01
statikmy gut answer is yes a group with no members could exist (and we'd probably want to have a couple special groups to start with), and no to storing groups within other groups20:01
statikalthough UI niceness to make it easy to perform actions on groups of people selected by combining tags would be good20:02
dobeythat's pretty much how i feel about that too20:03
aquariusgoogle contacts doesn't allow groups within groups as far as I can tell when I checked this a while back20:03
* aquarius checks again20:03
statikyeah i just confirmed that20:03
urbanapewell, if we're tying ourselves to an existing implementation, then forget anything I've suggested. It's useless to go down the ad-hoc tagging route, if we have to support arbitarily nestable hierarchies due to one client.20:03
Howard_Kindig_Does anyone know how to delete (unsubscribe) from a folder in Ubuntu One? (I accepted a share from someone else, and I now want to delete that folder from my account...but I don't see any way to do this...)20:03
dobeyurbanape: evolution doesn't work that way20:03
statiksame with OS X Address book, no groups within groups20:03
dobeystatik: and facebook as well20:04
aquariusurbanape, nah, we build what we think is best. If some client supports a more complex and rich taxonomy than we do, tough; that's a problem to be solved by that client's integration with the addressbook. this is what application_annotations is for.20:04
statikHoward_Kindig_, I think you can go to the web UI, select the folder and then reject the share. I will check now20:04
urbanapethen I'd vote no/no. Lightweight tags that are ephemeral but are super low cost to create.20:05
aquariusstatik, third reason to have groups as a separate entity; metadata for a group (Evo allows you to associate a picture with a category of contacts, for example)20:05
mandeldoing the lowest denominator is not a good idea usually...20:05
urbanapedeep hierarchies can be made with equivalent boolean searching.20:05
aquariusmandel, true, but if we try and make our system capable of modelling everything else that anyone has ever thought of, we end up in pain. Not gonna do that.20:05
statiktags feel more like how the world works, taxonomies seem doomed from the very beginning20:06
aquariusurbanape, I'm not totally wedded to the idea of nested groups. I am totally wedded to the idea of empty groups being able to exist.20:06
dobeystatik: well, they do contain the word 'tax"20:06
mandelif I have the right to vote, I would go for diff records or I implement them in macaco and we see what people think (if they use my code ofcourse)20:06
mandelwe can use my project as a playground area :P20:06
urbanapei agree with statik. I don't think there's much value in a tangible, empty group20:06
statikand i think we can do metadata on a group and empty groups by doing strange work around bodges in the implementation to track what tags we've seen20:06
urbanapenot when tagging is so inexpensive.20:07
aquariusurbanape, see example above about dragging "flatmates" out and then new flatmates into your "flatmates" category.20:07
statiki have a real world use case for an empty tag group, that i implemented on launchpad a while back (but never landed)20:07
rtgzanybody has anything against realpath() call?20:07
statikit was a search for all bugs that did not have any tags20:07
urbanapeaquarius: see previous comment: If we're tying ourselves to an implementation then I retract. You said we weren't tied to an implementation.20:07
statikso it showed up as a special hardcoded thing in the tag listing, and it felt pretty natural to use20:07
dobeyrtgz: for the Shared with Me symlink?20:07
rtgzdobey, yup20:08
urbanapepresenting them as folders is tied to an implementation, as far as I'm concerned.20:08
rtgzdobey, I don't like the idea to parse for 'Shared With Me'...20:08
dobeyrtgz: i don't recall exactly where we're getting that path from, but if it's from a NautilusFileInfo, then i think nautilus should be doing it, and giving us the real path20:08
dobeyrtgz: actually, i don't know why nautilus wouldn't be doing that already20:08
aquariusurbanape, we're not *tied* to it. However, I like the idea of being able to present them as folders, because it's good UI, and doing it your way flat rules that out. So you're explicitly *excluding* an implementation, and I don't think that the benefit we derive is worth it.20:08
mandelstatik, how did you implemented removing an empty group/tag?20:09
aquariusurbanape, from a UI perspective, it can still be presented as lightweight tagging if we want20:09
rtgzdobey, NautilusFileInfo returns info as seen by nautilus, and when it dives into the directory it reports about it as a proper dir :(20:09
statikhey jblount, Howard_Kindig_ was asking about how to reject a share after it's been accepted and I can't figure it out. where is this in the web UI?20:09
dobeyrtgz: sounds like a bug in nautilus20:09
rtgzdobey, I have checked available methods and members on NautilusFileInfo and it looks like that does not give enough info...20:09
Chipacaverterok: ping20:09
* rtgz thinks that #nautilus is waiting for him... again...20:10
jblountstatik: I don't think there is a way to do this, am I wrong?20:10
statikmandel: for this one, it was a hard coded tag that couldn't be deleted. what i'm imagining for other user created tags is that you have a view that shows all the tags and can directly delete it.20:10
jblountstatik: That is other than using the command line client thingie20:11
statikjblount, i don't know. sounds like something that we definitely should have!20:11
urbanapeaquarius: I think the question boils down to: are they tags (metadata on contacts) or are they bags, into which contacts (or representatives of contacts) can be placed?20:11
urbanapeI don't think you're going to find a model/representation that satisifies both equally well20:11
urbanapebecause they mean different things20:11
jblounturbanape: Can I say "get rid of this folder" to a folder shared with me in the web ui? I have no idea how.20:11
Howard_Kindig_I concur jblount & statik...as a user, right now I'm skunked...no way to delete a share that I've accepted.....20:12
aquariusurbanape, statik, I disagree. If you model a group as a separate entity, then you can present it as metadata on contacts in the UI.20:12
urbanapetags, a la flickr are not arbitrary folders making a hierarchy, though they can be browsed as a collection. However, once the last tag is gone, there is no tag20:12
urbanapejblount: I don't think so yet.20:12
jblountstatik: ^^ :(20:12
aquariusI'm basically OK with the idea of not allowing nested tags.20:12
urbanapeyou can rescind shares to other people20:12
urbanapebut you can't drop a share that you've accepted yet.20:13
statikwe could make tags sticky though, so they don't disappear when the refcount goes to zero20:13
urbanapestatik: bleah, then you've still got a "thing"20:13
aquariusnot without making them a separate entity20:13
Howard_Kindig_Yes--you can rescind the share if you're the owner...I'm the *recipient* of the share...(I accepted the share) and now I want to dump it...but no way to do so it seems.20:13
dobeystatik, Howard_Kindig_: i think there is an option to pass to u1sdtool to remove a share you've accepted20:13
urbanapeHoward_Kindig_: Yes, I just agreed to that.20:13
statikwe gotta fix this for Howard_Kindig_, this is terrible20:13
dobeybut i don't recall if that's totally true20:13
Howard_Kindig_I have a knack for finding bugs...it's a gift! :)20:14
mandelhas anyone read this about tag hierarchies: http://heymann.stanford.edu/taghierarchy.html20:14
aquariusdobey, it is20:14
urbanapeHoward_Kindig_: I think there's a bug filed on that. Lemme look20:14
aquariusHoward_Kindig_, you can reject a share from the command line (sorry it doesn't seem to be available from the web or desktop interfaces!)20:15
aquariusHoward_Kindig_, would you like me to talk you through that?20:15
Howard_Kindig_do you have the command?20:15
Howard_Kindig_Sure...walk thru would be great20:15
statikHoward_Kindig_, this is totally something we need in the webUI, but to fix your problem today you can use u1sdtool --list-shares, get the shareID, then use u1sdtool --reject-share=SHAREID20:15
aquarius"u1sdtool --list-shares" will show all the things that are shared with yo20:15
urbanapeHoward_Kindig_: https://bugs.edge.launchpad.net/~urbanape20:15
ubottuUbuntu bug 354174 in ubuntuone-servers "Rejecting or "unaccepting" shares in the webui" [High,Triaged]20:16
urbanapeyou can mark that as "Affects me too"20:16
aquariusHoward_Kindig_, the id will look like "6984d386-68eb-4075-858b-bb3453481da"20:16
Howard_Kindig_hmmm...ulsdtool command not found...20:16
rtgzbtw, just in order not to forget, it seems that removing the share does not remove the folder from the "other" pc.20:16
Howard_Kindig_do I have to be in a specific director?20:16
aquariusu1sdtool (u, digit 1, sdtool)20:16
aquariusit's the Ubuntu One (1) Sync Daemon tool :-)20:17
aquariusHoward_Kindig_, and once you've rejected that share, u1sdtool --list-shares will show that share as "accepted=False"20:18
statikmandel, i've not read that paper before thanks for the link. I'm thinking of something sort of like BeFS style live queries against attributes, where you can navigate by building a query rather than having a pre-built taxonomy20:19
aquariusyeah, I think that'll be fine to deal with the "do we need nested groups" question20:19
Howard_Kindig_u1sdtool --list-shares now showing "No shares" as a result...20:19
Howard_Kindig_So...good on the web, but that folder still is present on my desktop...(which isn't as much of an issue...I can delete that (I hope) from the command line?20:20
aquariusHoward_Kindig_, excellent; that should do it for you. It might take the web UI a little while to update to reflect that change.20:20
mandelstatik, that is something I was thinking to, but you surly can express it better than I do20:20
Howard_Kindig_Just did a refresh on the web and the change was reflected...20:20
Howard_Kindig_Will it eventually delete the no longer accepted share on my desktop?20:21
Howard_Kindig_(My Ubuntu One Folder)?20:21
Howard_Kindig_Or will I need to deleted that as root?20:21
statikverterok, do you know if we reject a share does the syncdaemon delete that share from the laptop, or does it have to be manually deleted?20:21
aquariusHoward_Kindig_, that...I'm not sure about, I'll be honest. verterok? if a previously-accepted share is rejected with u1sdtool, does chicharra delete the share folder?20:22
statikwe are in sync!20:22
verterokstatik: the data isn't deleted20:22
verterokHoward_Kindig_, aquarius ^20:23
statikverterok, thanks!20:23
verterokstatik, aquarius: we basically delete all traces of the share and it contents from the metadata20:23
verterokso, local_rescan don't find it in the next run20:23
statikaquarius, so i think i'm ok with groups disappearing when the last member is removed because we can Fake It in the User Interface to have a couple of hardcoded groups as breadcrumbs to let people know they can use groups.20:24
statiki don't know the answer to your point about metadata applied to a group though...20:24
aquariusstatik, I am way not keen on that. Example from above about a "flatmates" group, in a Nautilus-style UI (which is currently what we're angling towards), and also on metadata associated with a group.20:25
Howard_Kindig_Ok...so I've killed it on this machine now from the command line as root (since the share was not accessible to be deleted via my user account). BUT--I assume I'm going to now need to also delete that share from all the other computers I have on my Ubuntu One account manually....20:25
mandelstatik, John and I though about it, what about being able to give contact data to a group or other details20:25
Howard_Kindig_Thanks guys...appreciate the help!20:25
statikHoward_Kindig_, sorry about the rough edges, thanks for your patience20:25
aquariusHoward_Kindig_, no problem. Sorry this isn't quite as elegant yet as we'd like it to be20:25
mandelstatik, where Canonical has contact in it and urls such as the ubuntu url20:25
Howard_Kindig_It's all good...that's what open source is all about...constant development (and help when you need it!)   :)20:26
mandelaquarius, although I love the id of metadata for groups I think is far too early to think about it20:26
Howard_Kindig_Taking off...thanks again!20:27
statikmandel, exactly thats the thing i don't know how to answer. i have an idea but aquarius will say it's a nasty hack ;)20:27
aquariusmandel, I agree. I'm just trying to close as many future doors as we can while not closing ones that we really think we're going to need20:27
mandelstatick, aquarius, if you do not add metadata to the group people will never know since is something that few of us need20:28
statikand a taglike system just feels so good compared to LDAP or launchpad teams or other hierarchical approaches20:29
mandelquestion has anyone read: http://www.nobius.org/~dbg/practical-file-system-design.pdf might give ideas... (following statik comment of BeFS)20:29
statikthat is an awesome book20:29
statikdominic made me fall in love with C pointers in that book20:29
mandelstatik, do you recommend it?20:30
aquariusimagining that we come up with some dreadful hack for empty tags still existing, and imagining that we don't allow metadata on groups (neither of which I am convinced about, but go with it), I still want to be able to share a group.20:30
urbanapewhat's that mean?20:30
statikmandel, it's more about outdated implementation hacks and showing how to write a filesystem in userspace before porting it to the kernel. he's since gone on to work at google and then apple, on the spotlight team20:30
urbanapeshare the members?20:31
urbanapeor share the metadata (assuming there is some) of the group itself?20:31
mandelstatik, sounds good time, I like to know as mush as possible, even if outdated, I'll give it a go :)20:31
aquariusUse case: someone new joins my book-reading class, and we all collaborate on notes on a book via Ubuntu One. When they join, I add them to the group, and share the group record with them; they then know who else is in the group, *and* everyone else in the group gets an updated group record telling them about the new person.20:32
statikoh yeah, thats facebook20:32
aquariusand they'll automatically get access to our shared folder with the notes in, *because* the folder is shared to the group, not individually to all the people within it.20:32
statikyeah, group based access control starts to break down using a tag scheme. i think20:33
statiki mean, how to implement group based access control via a system that is tag based isn't immediately obvious to me.20:34
aquariusthink about it the alternate way (with tags): how would you do that situation? I tag the new person with "book study group". I go and find the shared folder and share it again to the new person. I then share the new person's contact record individually with all the other people in the group, and I share everyone else's contact record individually with the new person.20:34
mandelaquarius, I don't like the idea of sharing personal info of other people... includes legal problems and other headache... plus you have to start dealing with people that are in a group and do not want their info share, just part of it etc...20:34
aquariusthat's, like, sixteen steps.20:34
aquariusmandel, I've already worked all that out :)20:35
aquariusmandel, you, yourself, control what information you share with me. I can then share that information on, because, frankly, you can't stop me -- if you tell me your phone number, you can't stop me then telling it to urbanape :)20:35
urbanapebe wary of anyone who utters "I've already worked all that out"20:35
mandelaquarius, and what about partial replication (if it lands) to implement the group share using tags20:36
mandelreplicate record with a given tag to your friends db20:36
aquariusurbanape, that was hyperbole, I admit -- it was more to suggest "I'm not just making this up as I go along, I have put some thought into it" :-)20:36
urbanapethe only trouble I see with groups as tags is that you can't control who applies the tag.20:36
urbanapein that sense, yes, it is too ephemeral.20:36
urbanapewhen I worked at Socialtext, we were implmenting a user directory app.20:36
urbanapeit had both tags and groups, and needed them, because they're very different things.20:37
urbanapeGroups have membership, and tags are (again) ephemeral20:37
urbanapeNo one would tag someone as "subordinate" because there's no relationship there.20:37
urbanapegroups can reflect a relationship, where tags can't.20:38
urbanapeno one would go to the trouble to establish a *group* called "dog lovers"20:38
urbanapebut it's easy enough to apply to someone.20:38
dobeyrelationships shouldn't be done with tags or groups20:38
dobeythey should be done with relationship fields20:38
urbanapeall I'm saying is that the act of becoming a member of a group is a different act than self-identifying with a tag (or having that tag applied to you by someone else, if permitted)20:39
urbanapebecoming/being nominated to20:39
mandelwell tags are metadata, while groups are data, that in the main difference.. a tag is a second class citizen in my worlds20:39
dobeyurbanape: there are 3900 "dog lovers" groups on facebook :)20:39
urbanapedobey: when all you have is a hammer...20:39
dobeyurbanape: well, there are 60 pages now20:40
dobeyurbanape: but a group for dog lovers does make sense20:40
dobeyurbanape: at least in the sense of what a group is on facebook20:40
urbanapegroup membership entails a whole different mindset than being tagged something.20:40
statikverterok, not deleting shares when they are revoked was a deliberate design decision, right?20:40
dobeywhich is a forum for exchange and discussion20:40
urbanapemembership requires a different mental model than a tag20:41
dobeyyes it dose20:41
verterokstatik: yes20:41
urbanapebut I don't think they need to be exclusive.20:41
urbanapeor exclusory20:41
dobeyi should stop arguing about groups20:41
aquariusthe point here is: we can model both tags and groups from the user perspective if we have group entities in the data structure. If we only have tags in the data structure we can't really model groups from the user perspective.20:42
dobeyand do the SRUs20:42
dobeywhat is the difference between a group and a tag from the user perspective, really?20:42
verterokstatik: but we can easily delete a revoked share20:42
dobeygroups in this context are not things the members make a conscious decision to join or not join20:42
dobeywhich doesn't make it much of a group20:42
urbanapeaquarius: My revised point is that they are two different things, and maybe we should do them both.20:43
mandeldobey, group can exist by itself, tag need a contact to be present20:43
urbanapedobey: they absolutely do, if we're going to apply access rules to them.20:43
verterokstatik: one option to avoid data loss is to delete the share contents that we have in the metadata20:43
mandeldobey, metadata == tag, group == data which is aBIg diff20:43
verterokstatik: should we have a bug about this? :)20:43
urbanapethen we do need them to be consciously moderated20:43
dobeymandel: i don't believe in metadata20:43
dobeymandel: it's all just data to me20:43
aquariusno. a group isn't some sort of free-floating Platonic entity in empty space; it belongs to a person20:44
aquariusthat person can decide to share their group with others20:44
aquariusso someone becomes, essentially, "administrator" for that group, in the example of my book-reading club above20:44
urbanapeaquarius: no, groups are independent of a person20:44
mandeldobey, I do, example the metadata data is going to attack you20:44
statikverterok, yes please. your last idea, and filing a bug, sounds great20:44
aquariusurbanape, that's what I'm trying to avoid. I don't want independent groups, because then you need to worry about group ownership and so on and it's very complicated.20:45
mandeldobey, set metadata to big and data to dog, missing the metadata does not matter, missing the data does :P20:45
aquariusurbanape, and I'm trying to avoid having both groups and tags.20:45
urbanapeaquarius: that can't be avoided, especially if we're going to make access rules based on groups20:45
verterokstatik: ok :)20:45
aquariusurbanape, it can if you don't have tags.20:45
urbanapeaquarius: why? they're two different things20:45
aquariusnot to a punter they aren't.20:46
dobeymandel: "big" is an adjective, not metadata20:46
aquariusthey're different if you delve right into the detail.20:46
urbanapeare punters our audience?20:46
aquariusbut most people will not.20:46
urbanapeI aspire to have a smarter user20:46
aquariusurbanape, as opposed to people who think it's fun to talk about taxonomies, like us? yes, they are :)20:46
dobeydeploying knowledge is always the best option20:47
dobeybut taxonomies are the debil20:47
urbanapeno, I mean someone intuitively understanding that tagging their friend John with 'baking' doesn't necessarily put him in the "bakers" group.20:47
statikdat debil will git you ebery time20:47
mandeldobey, definition (or one) of adjective: not standing by itself, dependent, Metadata depend on data as an adjective depend on a noun20:47
aquariusurbanape, then that's two different groups, no?20:48
rtgzrealpath lost the battle. Current winner: canonicalize_file_name20:49
urbanapeI recant, I recant, I recant. Tags are not groups. Done.20:49
urbanapeboth have their purposes, and each has a distinct semantic20:49
statikaquarius, taking a step back, whats the future use cases for access control based on groups? stuff like we do with launchpad teams today, sharing and revoking a folder to a group rather than a bunch of individual people?20:49
urbanapeand while each can be an approximation of the other, doing so misses out.20:49
=== mandel is now known as mandel_afk
aquariusstatik, broadly, yes. Anywhere you can pick a person, you should be able to pick a group instead.20:50
statikright on20:50
statikso for the purposes of organizing my own contacts, tags seem the natural fit20:50
statikfor implementing an access control scheme, groups seem the natural fit20:50
dobeylike i said. no such thing as metadata :)20:51
statikapparently making software is complicated20:53
statikno wonder you guys work so hard on it20:53
urbanapeso, with the u1sdtool, how does the reject-share part work? We don't seem to have a view for that in the /files/ UI.20:53
statikurbanape, it sends a dbus command to the syncdaemon which sends a protocol message back to the api server20:53
urbanapewhich means we can't easily wire it up in javascript20:53
urbanapeif it's sending it to the api server, it must be hitting the api, yeah? I don't see a view that governs rejecting a share20:54
statikyeah, it would need a new view. it's kinda sad that our protocol is so separate from our rest API20:54
urbanapeI see deleting (rescinding) a share that I've made.20:54
statikthe twisted storage aPI server20:54
urbanapeyes, that is sad.20:54
statikin a totally fixable way of course. all we need is time.20:56
urbanapecan someone associated confirm that that message is "decline_share"?20:58
dobeyoh time20:59
* dobey would love to have more time20:59
urbanapeBecause I see that in the storage controller, and can probably wire it up through a view, and through javascript20:59
urbanapebut I don't know if decline_share is only tied to the offer or to the share after it's accepted, or both.21:00
urbanapeah, looks like our web controller does the mediating under the guise of "delete_share"21:01
urbanapeso we can use that for both (depending on who you are in the relationship, it calls the right method underneath)21:01
urbanapekinda gross.21:02
Chipacadobey: I have a mental stick note about talking to you about planning and ... something. Not sure what, seems the sticky note got dropped in nacho sauce or something21:02
urbanapemmmm, nachos21:02
dobeyChipaca: infrastructure fixings21:03
Chipacadobey: what kind of infrascrotal fixtures?21:03
Chipacawhoops, typo :-p21:04
dobeyChipaca: there's some work we need to get done on tarmac, and we need to get it running in a cron job in ec221:04
statikaquarius, now my head is spinning with groups. the whole sharing/access control thing is complicated21:04
statikwe need massive shared virtual whiteboards21:05
aquariusstatik, have you still got a copy of the groups & teams document I wrote up months ago?21:05
aquariusactually, I do believe it's on the wiki somewhere.21:05
Chipacastatik: can I context switch the hell out of you for a minute or five?21:05
statiki go into these twitching fits where i delete stuff. is it in ubuntu one? ah wiki, even beeter21:05
statikChipaca, i love context...hey a squirrel21:05
statikby which i mean i am at your service21:06
Chipacastatik: dobey wants tarmac fixed. Is that work for dobey himself, or is it something we can palm off on ops+? :)21:06
statikChipaca, you can dump it on ops+. pfibiger is supposed to be hiring someone21:07
Chipacadobey: can you spec up what work needs doing, so we can pass it on to ops+ and yell at them if they don't do it right?21:08
=== mandel_afk is now known as mandel
urbanapeSo, a thought: in the Web UI, I think a natural way to remove a folder that's been shared with you is to delete it. However, that's a conflicting (internally) gesture with being able to delete a shared folder to which you have write access. Or is it?21:08
dobeyChipaca: sure21:08
Chipacanot that we would do something as crass as yelling you understand21:08
urbanapeTo the user to whom the folder is shared, both actions have the same end.21:08
Chipacait's completely figurative21:08
urbanapeI.e., that damned folder no longer appears in my "Shared with Me" space.21:09
Chipacadobey: anything else?21:09
jblounturbanape: Maybe instead of a trash can there is some "unlink" sort of icon? Some other thing?21:09
aquariusurbanape, they're the same thing, aren't they? being able to "delete" a folder that you have write access to without unsharing it is a supremely pointless activity, since nine seconds later syncdaemon will just put it back21:09
urbanapewell, it sorta begs a question: Do we really ever intend to let people we share folders with (even read/write) delete the folder itself?21:09
aquariusnah, because it's not really a folder. it's a share, which we happen to model as a folder21:10
urbanapeaquarius: no, if I'm in the book study group, and I've been given read-write access to the folder, and I just want to drop the share, but click delete, boom. There it goes for everyone else.21:10
mandelneed to take a rest, please let me know if you made a decision on groups since it was my self imposed homework for the weekend, laters ;)21:11
aquariusthere's a difference between having write access to a share and being the owner of it, though21:11
urbanapeI'd imagine deleting a folder if I have r/w access actually deletes it, and syncdaemon should undersatnd that.21:11
urbanapeI don't see how.21:11
rtgzhmm..... can I share some directory with someone from those that were shared with me?...21:11
rtgzand in this case what will happen if someone shares with me something that I shared with them..21:11
rtgzIf I stare into the shared directory, the shared directory stares back into me21:12
aquariusdeleting a share folder if you own it should remove the share from everyone else; deleting a share folder if you don't own it should reject that share.21:12
Chipacartgz: no, no resharing21:12
urbanapertgz: typically, those are modeled as two separate permissions/actions21:12
urbanapeaquarius: is that actually codified anywhere?21:12
aquariusyou can't reject a share if you're owner of it, and you can't delete a share if you're not owner of it. So the cases are disjoint, and the action is unambiguous.21:12
rtgzsorry for reposts, reconnect happens...21:12
urbanapehow about deleting subfolders, if I've got read/write access?21:12
aquariusurbanape, it is technically possible that that's just how it Should Work, but I'm pretty sure that that's how it actually does work21:13
aquariusdeleting subfolders is fine; that'll delete them from everyone (that's what write access means), unless I've totally misunderstood, and if i have then I think syncdaemon is wrong. I don't think I have though!21:13
dobeyaquarius: well, i can delete the contents of a share if i was granted write permissions21:14
dobeywhich is somewhat effectively the same as deleting the share21:14
aquariusdobey, yep. there's not much difference between actually deleting a share and deleting all its contents, I admit, but there's not really a way around that.21:14
urbanapeyes, I don't see the distinction, if you've been granted write access21:14
aquariusthere is quite a big distinction in a world with history in it.21:14
aquariusIf you delete the contents, and you have history, you can get them back21:15
urbanapeif you delete a folder and have history you can get it back.21:15
urbanapeno difference, eh?21:15
aquariusif you delete the share, a recipient of that share can't get the files back, even with history, because they no longer have access to the share.21:15
urbanapeI feel like we're talking at cross purposes here.21:15
dobeywell, if we had history of who shared what to whom21:15
dobeythen that could be recovered as well21:15
dobeyChipaca: and then there's the planning thing21:16
Chipacadobey: yes. But I'm leaving; you want us to do it together tomorrow?21:16
dobeybut i'm more ad-hoc and spontaneous21:16
aquariusurbanape, model a share as follows. Oscar the Owner has a folder. He shares it read-write to William the Writer and shares it read-only to Roger the Reader.21:16
dobeyChipaca: that would be fine, sure21:16
Chipacadobey: yes, I know. Brownian would also be an adjective for that :)21:16
aquariusurbanape, if William deletes all the contents of the share, and there is history, Roger can still see the historical versions of the files (as can William and Oscar)21:17
urbanapeaquarius: In my mind, Roger can reject the share, which does nothing to the folder. William can reject the share, doing the same thing, but he can also delete the folder.21:17
aquariusurbanape, if Oscar deletes the share itself, then Roger no longer has any access to it, and therefore can't see the history21:17
urbanapeorthogonal to what I'm asking21:18
* Chipaca waves21:18
urbanapethere are two things that can be acted upon: the share, which is a relationship, and the folder, which is a content object.21:18
dobeyi think dpm deleted his branch(es)21:19
urbanapewhat started this whole mess is a proposition: that for a user who has had a folder shared with her, it is intuitive to "delete" the folder to make it go away from her "Shared with Me" stuff.21:19
aquariusagreed completely.21:19
aquariusI also think that it is intuitive fo a user who has shared a folder with others to "delete" the folder to both remove the contents and remove the share from others21:20
urbanapeSo, one thing we could say is: "Recipients of shares, even with write access, never delete folders via the trash can icon, they only delete shares"21:20
aquariusI agree.21:20
urbanapewell, sharing a folder with others doesn't place it in your "Shared with Me" area - it's still within your "My Files" area.21:20
urbanapeand yes, deleting it should delete any shares you've granted.21:21
urbanape(would be my expectation)21:21
aquariusI think the "folder" for a share actually represents that share itself; deleting it means "I don't want this share" if it was shared with you, and "delete all these files and unshare it with others" if you shared it with others21:21
aquariusso we agree, right?21:21
aquariusconfused about where we disagreed :)21:21
urbanapeno, but the effect is the same.21:21
urbanapewhat I'd propose is:21:21
urbanapewithin My Files, deleting a folder deletes the folder, also deleting any of its shares.21:22
urbanapewithin Shared with Me, "deleting" a folder merely deletes the share.21:22
urbanapealthough that only works at the root.21:22
urbanapefuck me.21:22
urbanapescrew this, I'm going shopping.21:23
dobeyverterok: ping21:23
aquariuswithin Shared With Me, deleting a root folder rejects the share.21:23
verterokdobey: pong21:23
dobeyverterok: does https://edge.launchpad.net/~verterok/ubuntuone-client/dont-delete-child-partials fix a bug? (there isn't one linked)21:23
urbanapeaquarius: not for subfodlers21:24
verterokdobey: the second part of the capabilities mismatch bug21:24
verterokdobey: actually the data loss that triggered the caps mismatch21:24
urbanapeI don't believe you can reject a share "somewhere down the stack"21:24
urbanapesorry, yes, root folder21:25
aquariusurbanape, yeah; deleting a non-root-folder within Shared With Me just deletes that folder (if you have rw access to the share) or denies you (if you have ro permissions)21:25
dobeyverterok: is there a bug # it should be linked to?21:25
dobeyverterok: i need bug #s to put it in the stable branch for SRU21:25
urbanapeHmm, I don't think our code differentiates "root folder" vs. "anything else"21:25
dobeyverterok: and it sounds like i need to put that in the SRU21:25
verterokdobey: there is, but I don't remember it21:25
urbanapeguess it probably could, given time.21:25
verterokdobey: gimme 1'21:26
urbanapeaquarius: so are we in violent agreement?21:26
aquariusurbanape, we are.21:26
verterokdobey: it's the bug with 1k dupes of caps mismatch21:26
urbanape"You're right!" "No, YOU'RE RIGHT!"21:26
* CardinalFang anticipates fisticuffs. 21:26
verterokdobey: Bug #46282821:30
ubottuLaunchpad bug 462828 in ubuntuone-client "Files are marked for deletion on server when syncdaemon is killed during sync" [Critical,Fix released] https://launchpad.net/bugs/46282821:30
dobeyverterok: ok, thanks!21:30
dobeyok, brb for real :)21:36
urbanapeCardinalFang: fisticuffs where we both punch ourselves.21:36
aquariusright, I'm going away. Cheers, all. Back tomorrow!21:45
dobeylater all22:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!