kklimondadidrocks: what is the status of OneConf? I'd love to see a synchronization of empathy logs (because I never remember to backup them myself) and I could even write something myself, if I even finish breaking^Hextending couchdb-glib ;)08:01
didrockskklimonda: oneconf is in universe and working, but desktopcouch synchronisation isn't… so the main inclusion was stuck because of that08:02
didrockskklimonda: normally, when desktopcouch synchronisation will be fixed, there is no change needed to oneconf to start appearing to people USC if they install it08:03
kklimondaright, everything seems to be broken because of that :)08:03
* kklimonda still can't access his contacts :/08:03
kklimondadidrocks: and what about message syncing? I have seen that rye has done some work, has he published it somewhere?08:04
didrockskklimonda: not sure about that, look at the stipple project08:05
ryekklimonda, not really published in a usable form, since i was unable to find the proper way to search through the conversations08:06
kklimondarye: ach, the only "good" idea would be to download all thousand or so of messages and use same function that is used in xml log store :/08:06
ryekklimonda, yes, or create a temporary vew which would literally 'grep' through the messages but that would take quite a few time08:08
ryeand telepathy project now has a dedicated observer for logging08:08
kklimondarye: it would take too much time and resources..08:08
kklimondarye: the best way to do it would be to, at last, get tracker working08:09
ryekklimonda, the other thing is that I don't feel like it is a right way to put every message into its own document, too much overhead for a simple ":)"08:09
kklimondabut it would require much more work08:09
kklimondarye: but on the other hand it simplify the replication08:10
kklimondarye: how much overhead is it really?08:10
ryekklimonda, http://blog.rtg.in.ua/2009/12/telepathy-logging-to-couchdb.html08:11
kklimondarye: It's hard to say without real data - what is the average length of message etc.?08:11
* rye goes to count characters08:12
kklimondarye: meh, last time I've checked my logs it was an average of 40 to 50 characters (I don't really remember anymore)08:13
kklimondarye: but then it may be completely dependant on users' habits08:13
kklimondarye: you could probably store "logical" pieces of conversations in their own documents - but how to decide where does one conversation end and another start?08:14
ryekklimonda, for those who use IM as an alternative to E-Mail it may be more, but for simple "-> Hi; <- Hello; -> Are you in $someplace; <- Yes; -> See you there" it will create rather big json object, and we don't really modify these documents ever08:15
kklimondarye: also the current xml log format also has overhead so the real question is "how much overhead is couchdb going to have"08:15
ryemuch like gwibber messages08:15
kklimondarye: but every time you append new message you have to pull it out, parse it, append new line of text and the put it in (probably deal with conflict)08:16
kklimondarye: It's not that uncommon to jump between your desktop IM and the one on your phone (mostly because jabber sucks at deciding which resource is active)08:17
kklimondaappend new message to the document with conversation08:18
ryekklimonda, just checked gwibber - search triggers api call to the servers, why do we keep thousands of twits in couchdb?08:19
kklimondarye: I *think* the couchdb backend has been disabled because it didn't work for gwibber.08:20
kklimondarye: kenvandine has said there were performance issues08:21
ryekklimonda, checking.....08:22
kklimondarye: afair because gwibber were talking to couchdb synchronously so that wouldn't be such an issue for tp-logger which works in background anyway08:22
ryekklimonda, hm08:24
kklimondaalso gwibber has like 10 different views, it probably takes a lot of time to update them ;)08:24
kklimondayou could probably do tp-logger backend using a single view, maybe two..08:25
ryekklimonda, true. Well, for telepathy storing of the message is ok (sans overhead) but i am mostly concerned about how to present the log to the user; time-based conversation split do not look good, and search will be slow08:26
kklimondarye: do you know how slow?08:26
kklimondarye: I don't think xml backend is that much faster08:27
kklimondaunless that's what the sqlite one is for :)08:27
ryekklimonda, no idea, since i left it thinking about how I would re-do that when I know more about python, telepathy and couchdb; well, i know more now but i still has not come up with an idea08:28
kklimondarye: we could use C, it's faster ;)08:28
kklimonda(also I'm not sure you can write tp-logger stores in anything but C)08:28
kklimondarye: btw, do you have idea what attachments are being compressed by couchdb? or do I have to explicitly set it somewhere?08:37
ryekklimonda, i foudn this http://wiki.apache.org/couchdb/HTTP_Document_API#Compression_of_Attachments while reading about the attachments but haven't tested this yet08:38
kklimondarye: ach, I haven't read the last sentence. Now it makes sense08:39
kklimondaby default those are compressed: text/*, application/javascript, application/json, application/xml08:40
kklimondawhich suits me just fine08:40
=== pedronis_ is now known as pedronis
kklimondarodrigo_: hey, do you have a moment?09:42
rodrigo_hi kklimonda09:42
kklimondarodrigo_: have you thought about putting and getting attachments to/from couchdb? I'm talking about couchdb-glib..09:44
rodrigo_kklimonda, yes, I started some kind of API, but it's unfinished09:44
rodrigo_see couchdb_document_foreach_attachment09:44
kklimondarodrigo_: right, I've seen this one :)09:45
kklimondarodrigo_: what about putting attachments into database? Should API make a distinction for standalone attachments and inline ones? CouchDB documentation mentions that using standalone attachments is more efficient but that would probably put one function in couchdb_document and another in couchdb_database..09:48
kklimondaor two different functions in couchdb_document namespace..09:48
rodrigo_kklimonda, from the API point of view, they are the same, so I was thinking to always default to standalone, seem to be more efficient09:48
kklimondarodrigo_: I guess the only problem with standalone is that you can't add attachment as a part of document creation.09:51
rodrigo_yeah, but the storage is more efficient09:52
rodrigo_you need a 2nd call to get the attachment though09:52
kklimondaso you would have to call couchdb_database_put_document () and then couchdb_document_add_attachment (or something like that)09:52
rodrigo_but I think it is more efficient09:52
rodrigo_what I don't remember very well is if you need to update the _attachments field in the doc when you add an attachment or if that is updated automatically09:52
kklimondayeah, but it's not consistent - you get a function that, instead of "lazy evaluation", immediately sends data to database.09:53
kklimondarodrigo_: it is updated automatically09:53
rodrigo_kklimonda, I guess we could have a couchdb_document_add_attachment, keep that in memory and when couchdb_database_put_document is called, do 2 calls, one for PUTing the doc and another for the attachment09:59
rodrigo_although if the attachment fails, we'd get in a weird situation10:00
rodrigo_kklimonda, btw, I'll branch today couchdb-glib, but after seeing your mail about CouchdbResponse/Request, you don't want your branch to be merged yet, right?10:03
kklimondarodrigo_: other option would be to create couchdb_database_add_attachment_to_document (and burn in hell for an ugly name)10:03
rodrigo_put_attachment might work10:04
kklimondarodrigo_: yeah, it doesn't make sense to merge it when I have to rewrite it anyway.10:04
rodrigo_although I'd prefer to do it on the Document object10:04
kklimondayeah, it does belong to Document after all10:04
rodrigo_kklimonda, ok, I'll look at your drafts later10:04
duanedesignmorning all12:14
ryeduanedesign, morning, bug #498019 is being actively hugged now :)12:23
ubot4Launchpad bug 498019 in ubuntuone-client (Ubuntu) (and 1 other project) "Nautilus crashes when anything Ubuntu One-related is clicked in the menu (affects: 11) (dups: 4) (heat: 54)" [Undecided,New] https://launchpad.net/bugs/49801912:23
rodrigo_hi duanedesign12:25
ryerodrigo_, synchronize this folder menu item does not appear to work12:26
rodrigo_rye, hmm, it does for me, let me retry12:27
ryerodrigo_, i.e. not via the checkbox but via the menu12:27
rodrigo_it jsut worked again12:27
rodrigo_rye, is sd connected?12:27
ryerodrigo_, wait, i have CreateUDF stuck in metadata12:28
ryerodrigo_, it's ok :)12:28
rodrigo_the menu item doesn't get refreshed though, I jsut saw12:28
ryerodrigo_, hmmm i think i found something else actually12:29
rye2010-09-22 14:29:20,409 - ubuntuone.SyncDaemon.DBus - DEBUG - Folders.create: dbus.String(u'/home/rtg/Desktop')12:29
rye2010-09-22 14:29:20,409 - ubuntuone.SyncDaemon.VM - DEBUG - create udf: '/home/rtg/Desktop'12:29
rye2010-09-22 14:29:20,413 - ubuntuone.SyncDaemon.VM - WARNING - Duplicated create_udf request for path (ingoring it!): '~'12:29
ryefacundobatista, hola! - what does that mean ^ ?12:30
rodrigo_hmm, you called it twice?12:30
facundobatistarye, hola!12:30
duanedesignrye: ahh, i saw a couple of those yesterday.12:31
ryeduanedesign, hm, it works after restart12:31
facundobatistarye, it says that you tried to create a duplicated UDF in "~"12:32
facundobatista(it doesn't log the UDF folder name in that line, only where it would be created)12:33
facundobatistarye, I just added an UDF and didn't get that warning12:40
ryefacundobatista, i believe i was rather quick in testing that - udf failed to be created but i clicked once more and more and more12:42
facundobatistaoh, ok12:42
ryedbus appmenu: http://ubuntuone.com/p/H5X/12:45
ryei found a bug in appmenu but i have no idea how i triggered it :)13:10
ryerodrigo_, so, after testing your branch i have to say that I could not have triggered the crashes13:37
ryerodrigo_, but I wonder whether e.g. context_menu_new should be prefixed by ubuntuone_nautilus in order not to cause any namespace collisions13:42
rodrigo_rye, what namespace collisions?13:53
rodrigo_rye, that's why I don't use a prefix, public functions usually have a prefix, but as you can see, we use location_widget, share_dialog, etc13:54
rodrigo_there shouldn't be no namespace collisions with any public function in any of the libs we link to13:54
ryerodrigo_, well, true13:54
=== beuno is now known as beuno-lunch
=== BlackZ_ is now known as BlackZ
=== beuno-lunch is now known as beuno
=== nessita1 is now known as nessita

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