=== eu is now known as Guest1946 === Guest1946 is now known as adorilson [17:26] hi. I'm still hacking a bit with the ubuntuone-storage-protocol code (here: https://code.launchpad.net/~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk ) to understand how it works, but I face a new problem [17:27] so following the protocol, I want to download a file on the server, so I send it a GetContent request, which is fine [17:32] it answers fine by the protocol with a NODE_ATTR message, followed by BYTES messages and ended by a EOF [17:54] but I fail to understand what 's in the BYTES messages. for example, in the case of an empty file, the BYTES message contains "x\234\003\000\000\000\000\001" [17:54] and I find nothing on google about it because it's so specific [17:56] it seems to be a raw array of bytes of some sort, but what I don't understand is that the content of the bytes message is nowhere near the "real" content of the file. I think of a kind of encoding, but I'm not sure [17:57] another example, for a file containing "hahaha\n", the bytes message sent to me by the server contains: "x\234\313H\314\000B.\000\n\265\002f" [17:58] so if anyone knows how it works. any help is appreciated ( dobey ? maybe you know ?) [18:00] what puzzles me even more is that when I look at the TestBytesProducer class or something on the repo, it seems to just open a file and directly send its content right into a bunch of bytes message, which seems logical [18:00] the BYTES message is a protobuf message [18:00] so I don't know why the server sends me this kind of thing... [18:01] also i think it might be compressed data [18:01] dobey < exactly. what I report is the content of msg.bytes.bytes, following the protocol [18:01] so the actual code will decompress it when writing it to a file [18:01] i don't really recall what that code does exactly though [18:01] given msg is a protobuf from ParseFromString [18:02] yes I think it might be compressed, but I don't know how to decompress it :-( already tried a lot of things [18:03] it would just be gzip [18:04] ah, I didn't try that ! [18:05] I'll let you know if it works [20:32] dobey < do you remember, if that's gzip, if there were any specific options to it ? [20:32] Pando: you're writing python code, yes? [20:32] when I gzip my file, it doesn't give me the same thing than what the u1 server sends me [20:32] yes [20:33] Pando: why are you trying to reimplement what ubuntuone-storage-protocol is already doing, anyway? [20:35] it's for a school project. we would like to bring ubuntu one support to our application, without having to add the twisted dependency [20:36] why not use the REST API then? [20:38] because the rest api doesn't allow partial down/uploads [20:38] at a given offset in a file, for example [20:39] and you can't just have ubuntuone-syncdaemon running, and just dump files into a directory that it is synchronizing? [20:40] and you want to sync arbitrary data, not simple structured data that can be stored in JSON? [20:46] well it would be a kind of synchronization application that would work with multiple platforms. U1 would be just one of them [20:46] the problem with the rest api is also that we don't have the notifications when something has been uploaded to the server [20:48] I've seen the DBus API, but it doesn't seem to allow precise control, like start a file uploading [20:48] well, you start a file uploading by just putting it in a directory that is managed by ubuntuone-syncdaemon [20:49] it gets the file change notification from the OS, and then uploads the file [21:05] sorry, phone [21:05] and then, when there is a change on the server, are we able to know what changed and how ? [21:07] there are signals on the dbus API for when a download starts/stops, and such, yes [21:21] that's something we got to think about. I recall that when I attempted to use the dbus api, I faced a problem that made me not use it, but I can't remember what right now. :) [21:22] I've got to go. thanks for your help dobey [21:23] ok