[00:04] mention 'python implementation of...' [00:04] where do the request IDs come from? [00:05] Web-address, and date [00:06] sub-heading "Protocol overview" above "+Since it is not well-documented elsewhere" [00:07] Link to http://code.google.com/apis/protocolbuffers/docs/overview.html after mention [00:10] tcole: impressive. excellent [00:10] tcole: (although I can't assess technical accuracy, yet) [00:10] * tcole nods [00:10] I'll make the changes you've suggested [00:12] probably note that 'python-gdata' contains the Google Buffer python implementation [00:12] actually, python-protobuf does [00:12] gdata is something else [00:13] right [00:13] and that's why I should mention python-protobuf explicitly :) [00:15] that ... request ID thing is an interesting question actually [00:16] for the client-iniated stuff I think we just use an incrementing counter [00:16] (it doesn't really matter) [00:16] but I'm not sure offhand what we do for server-initiated things [00:16] note that it doesn't matter [00:16] (eg. there is not need to call u1storage.generateRequestID() [00:21] ha [00:21] I missed an important detail [00:21] client request numbers are odd [00:21] and server-initiated request numbers are even [00:22] (effectively we use the low bit to create a separate namespace for client versus server-initiated things) [00:23] understatement ;-) [00:24] tcole: add README to debian/docs when it's done too. [00:25] ah, good catch; thanks! [00:27] uh, hmm [00:27] the comment here is wrong [00:27] in the code [00:27] I will need to fix that too... [00:27] or else I need to check what the server is doing [00:29] # we are a client, we do odd requests that one? [00:29] "# we are a client, we do odd requests" [00:30] would be clear to say "odd numbered request IDs (eg. 1,3,5,...)" or something [00:32] is this package used to implement ubunet too? [00:32] yes [00:35] remember not to accept any external contributions then [00:36] indeed [00:36] that's one reason why we split it out into a very minimal separate project/package [00:37] aside from the other good reasons to do so [00:37] we accept external contributions [00:37] there's no real reason not to [00:37] well, for the protocol bits [00:37] the server depends on that and it is AGPL [00:38] we do require the contributor agreement though [00:38] oh, right [00:38] I wasn't remembering far enough into the discussion [00:38] durr [00:38] this is what happens when I'm neck-deep in code and try to talk [00:38] well, we should review contributions well enough to not break things :) [00:39] It would be good to include the requirement for copyright assignement for any contributed patches [00:39] also, we'll want to get translations in protocol as well for any of the strings there [00:39] anyway, must go now [00:39] later [00:39] yes, the contributor agreement thing ought to be mentioned in the README as well [00:39] ...note the requirement for ... in the README [00:39] yup [00:39] yes [00:40] well, I'm amused [00:40] it seems the server currently uses even request IDs too :( [00:41] amused is the wrong word for what I am feeling [00:41] at least if I'm reading the code correctly [00:44] probably it doesn't matter as they're always used in one direction only [00:45] but if they do overlap that's most likely to affect debugging [00:52] yeah, thinking about it more [00:52] the way things are at the moment, it isn't likely to cause visible harm [00:52] but still should be fixed [00:52] I put in an ubunet bug [00:52] I think we're beyond changing it on the clients at this point [00:53] hm, I think that does it for me for tonight [00:53] I just pushed more updates to the README [00:53] probably look at getting that landed monday [01:00] * sladen bzr pulls [01:08] also fixed the comments in the actual code to match what the client does and the readme says [01:14] 00:29 < sladen> "# we are a client, we do odd requests" [01:14] 00:30 < sladen> would be clear to say "odd numbered request IDs (eg. 1,3,5,...)" or something [01:15] oops [02:06] tcole: 'protoc' itself appears to actually be in 'protobuf-compiler' [02:07] hm, isn't that what I said in the readme? [02:07] that protoc was available via the protobuf-compiler package? [02:07] or did I word it confusingly? [02:10] it currently talks about python-protobuf; I haven't used either so I dont know to what extent that package is needed directly [02:13] you guys still at it? [02:13] lol [02:22] is/was 'idisk' a codename? [02:22] < sladen> tcole: it currently talks about python-protobuf; I haven't used either so I dont know to what extent that package is needed directly [02:23] idisk was never a codename for us that I'm aware of [02:23] and python-protobuf is a typo [02:24] or, well [02:24] need both python-protobuf and protobuf-compiler I guess [02:26] pushed fix [02:31] tcole: re: "This protocol applies only to the file storage service and not other Ubuntu One services." if this protocol is built on top of another protocol, what is the protocol below [02:31] I don't understand the question. [02:31] tcole: eg. how does the server differientiate storage-protocol from email-protocol from foo-prtocol [02:32] different ports, at least [02:32] typically different servers on the backend as well [02:32] oh right. [02:33] I take it this doesn't work particulary well via HTTP proxy servers [02:33] so port 20100 is u1storage [02:36] actually, no [02:36] it does SSL on port 443 [02:37] parser.add_option("--port", dest="port", metavar="PORT", [02:37] default=443, [02:37] help="The port on which to connect to the server") [02:37] parser.add_option("--host", dest="host", metavar="HOST", [02:37] default='fs-1.ubuntuone.com', [02:37] help="The server address") [02:37] actually we just have different servers [02:37] as long as the firewall allows https through it should allow this [02:39] is this an HTTPS channel (that happens to be on port 443) [02:39] just raw SSL, IIRC [02:39] or this a RAW TCP channel (that just ... okay [02:43] so SSL is setup, keys checked etc, and then instead of HTTP, the u1storage binary application of google buffer is spoken back/forth [02:44] most interesting [02:45] so ubunet is not a monolithic app on a single machine [02:45] it's an app that happen to listen on one particular port on one particular machine and speak just one protocol [02:45] (ubut [02:46] tcole: who do I ask in the ubunet team to find out what they actually call/refer daemon running on fs-1.ubuntuone.com [02:47] well, lucio who will be here on Monday is the foremost expert on it [02:47] but we call it the "API server" [02:47] which is not really the most helpful/descriptive name [02:47] <__lucio__> storage api server should be good enough [02:48] yes, though we shall have to distinguish file storage and structured storage eventually [02:50] __lucio__: is that what you actually called it when chatting over the coffee table? [02:50] s/called/call/ [02:50] <__lucio__> tcole: i imagine structure storage will go by the name of couch something [02:51] sladen: it's been "server" or "api server" mostly.. [02:51] <__lucio__> sladen: we called it the server, but i dont hitnk that will help you at all. then the API server. i complained about that becuase thats also too generic. so storge api server is the closest name i can think of that devs will understand what you re talking about and it makes sense to people from the outside [02:52] sladen: if it makes you feel better, we call the syncdaemon chicharra sometimes [02:52] <__lucio__> hitnk == think in some places south of the ecuador [02:54] <__lucio__> luckily, you dont need to know what we call each other :) [02:55] so "ubunet storage api server" [02:55] s/ubunet/ubuntu one/ [02:56] no, "ubuntu one" is the this vague term that is causing alot of respentment, confusion and complication from being vague [02:57] I'm doing my best to try and track down how to (accurately and colloquially) refer to the componets in the stack in ways that do not use the phrase "ubuntu one" [02:58] that phrase is tarnished, it's useless as anything other than a marketing brand [02:59] (where being vague + all encompassing *is* the desired result) [02:59] it's the difference between CLI, CLR, CTS, C# and ".Net" [03:06] the latter is useful for a Microsoft sales-person, but it is of little use to a Mono developer needing to articulate the finer points of a JIT compiler [03:08] <__lucio__> i would still advise against using ubunet. it means nothing now. [03:09] __lucio__: mmm. [03:09] __lucio__: what's the actual binary running fs-1.ubuntu.com called? [03:10] /usr/bin/python :) [03:10] <__lucio__> sladen: canonical/ubuntuone/storage/server/server.py [03:11] crikey [03:14] maybe we should start giving things ikea names [03:15] I'm slightly amazed that names haven't developed on their own [03:15] it's a shame we couldn't legally use "hammertime" [03:19] eg. if I'm discussing a component in Launchpad I can succinctly refer to Malone/Soyuz/Rosetta [03:21] you just tweak it slightly; eg. hammermime [03:24] Suppose I could just do what that magazine did for the Spice Girls [03:25] make so up and see if they stick [03:37] tammerhime? [03:43] Hammermime, now that would be something to see. [03:43] BTW, sladen thanks VERY much for your bug reports today [03:43] I'm one of the guys on the team learning packaging dos and don'ts and they were VERY helpful [03:44] * rmcbride returns to weekend-lurk mode [05:25] wow [06:48] How can I get an invite to ubuntuone? currently using Dropbox just want to give ubuntuone a run [11:01] mmm, so loking at what would be shared between hammertime and any future email/calendar sync, AFAICT, the only common element would be the use of python-protobuf [11:26] lifeless: yeah, 'hammerhime' would have the edge on pronoucnability [12:06] how is "storagefs" used in general conversation [12:11] __lucio__: up one more level; what's the file in /etc/init.d/ that runs /usr/bin/env python canonical/ubuntuone/storage/server/server.py after a reboot [12:12] __lucio__: don't tell me, that's called canonical-ubuntuone-storage-server.sh ... [13:20] o is there a web-based [D[D[D[D[D[D[D[D[D[D[D[B[B[B[B [13:20] is there a web-based interface to u1sync aswell? (as part of ubunet and exposed by HTTPS?) [13:20] Hi everybody! Is there a changelog or something that describes bugfixes ect. of new ubuntuone-client versions somewhere? thx! [13:21] https://bugs.edge.launchpad.net/ubuntuone-client/+bug/384065 seems to suggest that it does [13:21] Launchpad bug 384065 in ubuntuone-client "I had a problem with...uploading files to web interface, cannot drag and drop to folder access denied" [Undecided,New] [13:21] if so, what is this called [14:03] sladen: u1sync doesn't have a special web interface of its own, no. that bug is confusing as it's a few bugs in one [14:04] dobey: okay. Any idea what is referring to? [14:05] dobey: (the webbrowser reference) [14:05] sladen: the main issues seem to be that a) ubuntuone is slow for uploading his data, and b) the local interface to uploading files is a bit confusing (which is filed as another bug) [14:05] sladen: https://ubuntuone.com/files/ <- web ui [14:07] dobey: what does that URL give (if you're successfully logged in). Is it a directory listing equivalent to the contents of ~/Ubuntu One/ [14:08] sladen: it's a file browser view effectively similar to viewing ~/Ubuntu One/ in browser mode in nautilus, yes [14:10] dobey: and you can do upload/download operations equivalent to those undertaken by u1sync-agent [14:10] you can upload files and download files via the web, yes [14:10] dobey: and you can do upload/download operations equivalent to those (handed to the nautilaus extension) and undertaken by u1sync-agent [14:11] the nautilus extension doesn't do anything with files [14:11] it simply sets emblems based on status, and provides UI to share folders [14:11] and a button to connect/disconnect the service [14:17] sigh. palm pre has some ui issues :-( [14:18] and why the hell won't it log in to my mail server :-/ [14:35] dobey: interestingly, that nautilus extensions won't have worked for anyone except on amd64 (or whatever arch the buildds are) [14:40] sladen: how do you figure? [14:55] sladen: the nautilus extension is currently in python... so it's architecture independent (the ubuntuone-client package is built for architecture all) [14:55] sladen: and when I finish the C port of it, it will still build on any architecture just fine, and even should work on win32 if you are running nautilus on win32 [14:57] dobey: yeah, but that .so file is only being compiled as the architecture of the buildd in question. (bug #384276) [14:57] Launchpad bug 384276 in ubuntuone-client "Architecture: all but includes libnautilus-u1sync.so" [Undecided,New] https://launchpad.net/bugs/384276 [14:58] it works on all platforms, but only if compiled for each (Architecture: _any_) [14:58] eh [14:59] basic computing 101, different processors have different instruction sets [14:59] i386 binaries do not run on powerpc [14:59] amd64 binaries do not run on sparc [15:00] arm binaries do not run on ia64 [15:01] python programs, SVG images files, shell scripts; work on all processor types without recompiling, because they are interpreted and not compiled to the native instruction set [15:02] C libraries must be compiled for each processor type, and the result binary (and package) will only work on that processor type [15:03] i know how architectures work. thank you very much. [15:05] and there isn't an .so in the debian package [15:07] apologies if there isn't. What is the file in nautilus/ubuntuone-nautilus.c compiled to? [15:07] it's not currently compiled by the package build [15:07] it's the in-process port of the extension to C [15:09] ah, so it's not used yet [15:10] right [15:10] The current code being canonical/ubuntuone/nautilus/nautilus_api.py [15:15] what's "fsm" ? [15:17] file something manager [15:17] sladen: the current code being nautilus/storage.py actually [15:22] finite state machine? [15:26] dobey: if an {email,calendar,...} client is written, would have use 'python-u1storage' ? [15:26] dobey: if an {email,calendar,...} client is written, would that use 'python-u1storage' ? [15:26] or what is have it's down low-level protocol [15:26] or maybe finite state machine [15:27] the 'structured storage' thing that we're going to release soon will use the couchdb protocol for replication [15:28] so that's won't share (any) code with the u1sync/u1storage stuff currently released? [15:31] the only thing in common is that that it falls under the same "Ubuntu One" high-level project name [15:32] i don't know what all exactly is shared for code with that, as i haven't been working on it. i've been working on the file storage stuff === thekorn_ is now known as thekorn [15:32] but ubuntuone-storage-protocol is the protocol for filesystem level storage stuff [15:32] ie, the "this is for storing files, not simple text records like contacts/events" [15:33] hrmm, i wonder if i can theme the palm pre [15:33] probably requires mucking about with the firmware though :( [15:35] I'm trying to get my head around whether replication stuff (in general, not just of files) is built on top of a replicated filesystem protocol (u1storage, currently (only) implemented by ubuntuone-storage-protocol) [15:37] or if u1storage, (a convenience library for remote file access currently called ubuntuone-storage-protocol) is/is going to be implemented on top of some more generic blob/sha1 hash notification system [15:37] I think I confused even myself in writing those two lines [15:37] I'll go and read the code again and try to guess [15:40] ... [15:41] dobey: does the http://ubuntuone.com/files/ work with directories uploaded using the u1sync commandline/ftp tool (not the u1sync-agent) [15:42] sladen: ubuntuone.com/files/ shows you what is in your subscribed storage account. if you upload a directory with u1sync, it will be under My Files/ yes [15:44] BUGabundo: any chance you could do me a screenshot showing http://ubuntuone.com/files/ with both some files/stuff synced via your ~/Ubuntu One/ directory, and also some stuff sycned via the commandline u1sync tool ? [15:52] sladen: not now [15:54] palm pre is sexy, but i really don't want all of my aim/facebook/etc contacts to show up everywhere :( [15:54] on an Assembly [16:04] <__lucio__> sladen: i thin its called /etc/init.d/ubuntuoneapiserver [16:48] later [16:49] dobey: later [16:52] BUGabundo: later [16:53] artir: I'm staying [16:53] lol [16:53] I didn't saw the dobey: [16:53] xd [17:14] __lucio__: dobey: can you tell me what "updown server" refers to? [17:14] <__lucio__> sladen: its the server that handles the web uploads and downloads [17:17] __lucio__: so does updown use canonical.ubuntuone.storage.protocol to connect to fs-1 just like another client, or does it access the disk directly [17:19] <__lucio__> it doesnt use the protocol, no [17:27] can somebody remove the Milestone on https://bugs.launchpad.net/ubuntuone-client/+bug/377346 and repoint it at the server-end (ubunet) [17:27] Launchpad bug 377346 in ubuntuone-client "1st file upload - via webinterface: [Errno 28] No space left on device" [High,Triaged] [17:27] it doesn't relate to the client software at all [17:36] with regspect to oauthenciation, what do 'rtu', 'uau', 'atu' refer to? I'm presuming the 't' is '-to-' [17:39] and same with https://bugs.launchpad.net/ubuntuone-client/+bug/326256 can somebody remove the milestone, repoint it to ubunet and restore the milestone as it doesn't relate to the client software in any way [17:39] Launchpad bug 326256 in ubuntuone-client "Trial Signup: View ToS in larger window replaces the "action" page" [Medium,Confirmed] [18:29] __lucio__: what/who is "ISD" ? [18:59] rmcbride: regarding 100meg.file etc, is it really that big? [18:59] rmcbride: and for things like the JPGs, what's the license of those? === yofel_ is now known as yofel