| 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:01 |
| didrocks | kklimonda: oneconf is in universe and working, but desktopcouch synchronisation isn't… so the main inclusion was stuck because of that | 08:02 |
| 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:03 | |
| kklimonda | didrocks: and what about message syncing? I have seen that rye has done some work, has he published it somewhere? | 08:04 |
| didrocks | kklimonda: not sure about that, look at the stipple project | 08:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| kklimonda | rye: but on the other hand it simplify the replication | 08:10 |
| kklimonda | rye: how much overhead is it really? | 08:10 |
| 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:11 |
| * rye goes to count characters | 08:12 | |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| kklimonda | append new message to the document with conversation | 08:18 |
| rye | kklimonda, just checked gwibber - search triggers api call to the servers, why do we keep thousands of twits in couchdb? | 08:19 |
| kklimonda | rye: I *think* the couchdb backend has been disabled because it didn't work for gwibber. | 08:20 |
| kklimonda | rye: kenvandine has said there were performance issues | 08:21 |
| 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:22 |
| rye | kklimonda, hm | 08:24 |
| kklimonda | also gwibber has like 10 different views, it probably takes a lot of time to update them ;) | 08:24 |
| kklimonda | you could probably do tp-logger backend using a single view, maybe two.. | 08:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| kklimonda | rye: btw, do you have idea what attachments are being compressed by couchdb? or do I have to explicitly set it somewhere? | 08:37 |
| 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:38 |
| kklimonda | rye: ach, I haven't read the last sentence. Now it makes sense | 08:39 |
| kklimonda | by default those are compressed: text/*, application/javascript, application/json, application/xml | 08:40 |
| kklimonda | which suits me just fine | 08:40 |
| === pedronis_ is now known as pedronis | ||
| kklimonda | rodrigo_: hey, do you have a moment? | 09:42 |
| rodrigo_ | hi kklimonda | 09:42 |
| 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:44 |
| kklimonda | rodrigo_: right, I've seen this one :) | 09:45 |
| 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:48 |
| kklimonda | rodrigo_: 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 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:52 |
| 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: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 attachment | 09:59 |
| rodrigo_ | although if the attachment fails, we'd get in a weird situation | 10: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 |
| kklimonda | rodrigo_: 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 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 | 10:04 |
| duanedesign | morning all | 12:14 |
| 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:23 |
| rodrigo_ | hi duanedesign | 12:25 |
| rye | rodrigo_, synchronize this folder menu item does not appear to work | 12:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| rye | facundobatista, hola! - what does that mean ^ ? | 12:30 |
| rodrigo_ | hmm, you called it twice? | 12:30 |
| facundobatista | rye, hola! | 12:30 |
| duanedesign | rye: ahh, i saw a couple of those yesterday. | 12:31 |
| rye | duanedesign, hm, it works after restart | 12:31 |
| facundobatista | rye, 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 |
| facundobatista | rye, I just added an UDF and didn't get that warning | 12:40 |
| 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:42 |
| rye | dbus appmenu: http://ubuntuone.com/p/H5X/ | 12:45 |
| rye | i found a bug in appmenu but i have no idea how i triggered it :) | 13:10 |
| rye | rodrigo_, so, after testing your branch i have to say that I could not have triggered the crashes | 13:37 |
| 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: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, 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 | 13: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!