[08:01] <kklimonda> didrocks: 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] <kklimonda> ever*
[08:02] <didrocks> kklimonda: oneconf is in universe and working, but desktopcouch synchronisation isn't… so the main inclusion was stuck because of that
[08:03] <didrocks> kklimonda: normally, when desktopcouch synchronisation will be fixed, there is no change needed to oneconf to start appearing to people USC if they install it
[08:03] <kklimonda> right, everything seems to be broken because of that :)
[08:03]  * kklimonda still can't access his contacts :/
[08:04] <kklimonda> didrocks: and what about message syncing? I have seen that rye has done some work, has he published it somewhere?
[08:05] <didrocks> kklimonda: not sure about that, look at the stipple project
[08:06] <rye> kklimonda, not really published in a usable form, since i was unable to find the proper way to search through the conversations
[08:06] <kklimonda> rye: 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:08] <rye> kklimonda, yes, or create a temporary vew which would literally 'grep' through the messages but that would take quite a few time
[08:08] <rye> and telepathy project now has a dedicated observer for logging
[08:08] <rye> tp-logger
[08:08] <kklimonda> rye: it would take too much time and resources..
[08:09] <kklimonda> rye: the best way to do it would be to, at last, get tracker working
[08:09] <rye> kklimonda, 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] <kklimonda> but it would require much more work
[08:10] <kklimonda> rye: but on the other hand it simplify the replication
[08:10] <kklimonda> rye: how much overhead is it really?
[08:11] <rye> kklimonda, http://blog.rtg.in.ua/2009/12/telepathy-logging-to-couchdb.html
[08:11] <kklimonda> rye: It's hard to say without real data - what is the average length of message etc.?
[08:12]  * rye goes to count characters
[08:13] <kklimonda> rye: 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] <kklimonda> rye: but then it may be completely dependant on users' habits
[08:14] <kklimonda> rye: 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:15] <rye> kklimonda, 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 ever
[08:15] <kklimonda> rye: also the current xml log format also has overhead so the real question is "how much overhead is couchdb going to have"
[08:15] <rye> much like gwibber messages
[08:16] <kklimonda> rye: 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:17] <kklimonda> rye: 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:18] <kklimonda> append new message to the document with conversation
[08:19] <rye> kklimonda, just checked gwibber - search triggers api call to the servers, why do we keep thousands of twits in couchdb?
[08:20] <kklimonda> rye: I *think* the couchdb backend has been disabled because it didn't work for gwibber.
[08:21] <kklimonda> rye: kenvandine has said there were performance issues
[08:22] <rye> kklimonda, checking.....
[08:22] <kklimonda> rye: afair because gwibber were talking to couchdb synchronously so that wouldn't be such an issue for tp-logger which works in background anyway
[08:24] <rye> kklimonda, hm
[08:24] <kklimonda> also gwibber has like 10 different views, it probably takes a lot of time to update them ;)
[08:25] <kklimonda> you could probably do tp-logger backend using a single view, maybe two..
[08:26] <rye> kklimonda, 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 slow
[08:26] <kklimonda> rye: do you know how slow?
[08:27] <kklimonda> rye: I don't think xml backend is that much faster
[08:27] <kklimonda> unless that's what the sqlite one is for :)
[08:28] <rye> kklimonda, 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 idea
[08:28] <kklimonda> rye: 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:37] <kklimonda> rye: btw, do you have idea what attachments are being compressed by couchdb? or do I have to explicitly set it somewhere?
[08:38] <rye> kklimonda, i foudn this http://wiki.apache.org/couchdb/HTTP_Document_API#Compression_of_Attachments while reading about the attachments but haven't tested this yet
[08:39] <kklimonda> rye: ach, I haven't read the last sentence. Now it makes sense
[08:40] <kklimonda> by default those are compressed: text/*, application/javascript, application/json, application/xml
[08:40] <kklimonda> which suits me just fine
=== pedronis_ is now known as pedronis
[09:42] <kklimonda> rodrigo_: hey, do you have a moment?
[09:42] <rodrigo_> hi kklimonda
[09:44] <kklimonda> rodrigo_: 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 unfinished
[09:44] <rodrigo_> see couchdb_document_foreach_attachment
[09:45] <kklimonda> rodrigo_: right, I've seen this one :)
[09:48] <kklimonda> rodrigo_: 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] <kklimonda> or 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 efficient
[09:51] <kklimonda> rodrigo_: I guess the only problem with standalone is that you can't add attachment as a part of document creation.
[09:52] <rodrigo_> yeah, but the storage is more efficient
[09:52] <rodrigo_> you need a 2nd call to get the attachment though
[09:52] <kklimonda> so 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 efficient
[09: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 automatically
[09:53] <kklimonda> yeah, but it's not consistent - you get a function that, instead of "lazy evaluation", immediately sends data to database.
[09:53] <kklimonda> rodrigo_: it is updated automatically
[09:53] <rodrigo_> ok
[09:59] <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 attachment
[10:00] <rodrigo_> although if the attachment fails, we'd get in a weird situation
[10:03] <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] <kklimonda> rodrigo_: other option would be to create couchdb_database_add_attachment_to_document (and burn in hell for an ugly name)
[10:04] <rodrigo_> put_attachment might work
[10:04] <kklimonda> rodrigo_: 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 object
[10:04] <kklimonda> yeah, it does belong to Document after all
[10:04] <rodrigo_> kklimonda, ok, I'll look at your drafts later
[12:14] <duanedesign> morning all
[12:23] <rye> duanedesign, morning, bug #498019 is being actively hugged now :)
[12:23] <ubot4> Launchpad 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/498019
[12:25] <rodrigo_> hi duanedesign
[12:26] <rye> rodrigo_, synchronize this folder menu item does not appear to work
[12:27] <rodrigo_> rye, hmm, it does for me, let me retry
[12:27] <rye> rodrigo_, i.e. not via the checkbox but via the menu
[12:27] <rodrigo_> yeah
[12:27] <rodrigo_> it jsut worked again
[12:27] <rodrigo_> rye, is sd connected?
[12:28] <rye> rodrigo_, wait, i have CreateUDF stuck in metadata
[12:28] <rye> rodrigo_, it's ok :)
[12:28] <rodrigo_> ah
[12:28] <rodrigo_> the menu item doesn't get refreshed though, I jsut saw
[12:29] <rye> rodrigo_, hmmm i think i found something else actually
[12:29] <rodrigo_> what?
[12:29] <rye> 2010-09-22 14:29:20,409 - ubuntuone.SyncDaemon.DBus - DEBUG - Folders.create: dbus.String(u'/home/rtg/Desktop')
[12:29] <rye> 2010-09-22 14:29:20,409 - ubuntuone.SyncDaemon.VM - DEBUG - create udf: '/home/rtg/Desktop'
[12:29] <rye> 2010-09-22 14:29:20,413 - ubuntuone.SyncDaemon.VM - WARNING - Duplicated create_udf request for path (ingoring it!): '~'
[12:30] <rye> facundobatista, hola! - what does that mean ^ ?
[12:30] <rodrigo_> hmm, you called it twice?
[12:30] <facundobatista> rye, hola!
[12:31] <duanedesign> rye: ahh, i saw a couple of those yesterday.
[12:31] <rye> duanedesign, hm, it works after restart
[12:32] <facundobatista> rye, it says that you tried to create a duplicated UDF in "~"
[12:33] <facundobatista> (it doesn't log the UDF folder name in that line, only where it would be created)
[12:40] <facundobatista> rye, I just added an UDF and didn't get that warning
[12:42] <rye> facundobatista, i believe i was rather quick in testing that - udf failed to be created but i clicked once more and more and more
[12:42] <facundobatista> oh, ok
[12:45] <rye> dbus appmenu: http://ubuntuone.com/p/H5X/
[13:10] <rye> i found a bug in appmenu but i have no idea how i triggered it :)
[13:37] <rye> rodrigo_, so, after testing your branch i have to say that I could not have triggered the crashes
[13:42] <rye> rodrigo_, but I wonder whether e.g. context_menu_new should be prefixed by ubuntuone_nautilus in order not to cause any namespace collisions
[13:53] <rodrigo_> rye, what namespace collisions?
[13:54] <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, etc
[13:54] <rodrigo_> there shouldn't be no namespace collisions with any public function in any of the libs we link to
[13:54] <rye> rodrigo_, well, true
=== 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