[00:04] <sladen> mention 'python implementation of...'
[00:04] <sladen> where do the request IDs come from?
[00:05] <sladen> Web-address, and date
[00:06] <sladen> sub-heading "Protocol overview" above "+Since it is not well-documented elsewhere"
[00:07] <sladen> Link to http://code.google.com/apis/protocolbuffers/docs/overview.html  after mention
[00:10] <sladen> tcole: impressive.  excellent
[00:10] <sladen> tcole: (although I can't assess technical accuracy, yet)
[00:10]  * tcole nods
[00:10] <tcole> I'll make the changes you've suggested
[00:12] <sladen> probably note that 'python-gdata' contains the Google Buffer python implementation
[00:12] <dobey> actually, python-protobuf does
[00:12] <dobey> gdata is something else
[00:13] <tcole> right
[00:13] <tcole> and that's why I should mention python-protobuf explicitly :)
[00:15] <tcole> that ... request ID thing is an interesting question actually
[00:16] <tcole> for the client-iniated stuff I think we just use an incrementing counter
[00:16] <tcole> (it doesn't really matter)
[00:16] <tcole> but I'm not sure offhand what we do for server-initiated things
[00:16] <sladen> note that it doesn't matter
[00:16] <sladen> (eg. there is not need to call   u1storage.generateRequestID()
[00:21] <tcole> ha
[00:21] <tcole> I missed an important detail
[00:21] <tcole> client request numbers are odd
[00:21] <tcole> and server-initiated request numbers are even
[00:22] <tcole> (effectively we use the low bit to create a separate namespace for client versus server-initiated things)
[00:23] <sladen> understatement ;-)
[00:24] <sladen> tcole: add README to debian/docs when it's done too.
[00:25] <tcole> ah, good catch; thanks!
[00:27] <tcole> uh, hmm
[00:27] <tcole> the comment here is wrong
[00:27] <tcole> in the code
[00:27] <tcole> I will need to fix that too...
[00:27] <tcole> or else I need to check what the server is doing
[00:29] <sladen> # we are a client, we do odd requests that one?
[00:29] <sladen> "# we are a client, we do odd requests"
[00:30] <sladen> would be clear to say   "odd numbered request IDs (eg. 1,3,5,...)" or something
[00:32] <sladen> is this package used to implement ubunet too?
[00:32] <tcole> yes
[00:35] <sladen> remember not to accept any external contributions then
[00:36] <tcole> indeed
[00:36] <tcole> that's one reason why we split it out into a very minimal separate project/package
[00:37] <tcole> aside from the other good reasons to do so
[00:37] <dobey> we accept external contributions
[00:37] <dobey> there's no real reason not to
[00:37] <tcole> well, for the protocol bits
[00:37] <tcole> the server depends on that and it is AGPL
[00:38] <dobey> we do require the contributor agreement though
[00:38] <tcole> oh, right
[00:38] <tcole> I wasn't remembering far enough into the discussion
[00:38] <tcole> durr
[00:38] <tcole> this is what happens when I'm neck-deep in code and try to talk
[00:38] <dobey> well, we should review contributions well enough to not break things :)
[00:39] <sladen> It would be good to include the requirement for copyright assignement for any contributed patches
[00:39] <dobey> also, we'll want to get translations in protocol as well for any of the strings there
[00:39] <dobey> anyway, must go now
[00:39] <dobey> later
[00:39] <tcole> yes, the contributor agreement thing ought to be mentioned in the README as well
[00:39] <sladen> ...note the requirement for ... in the README
[00:39] <sladen> yup
[00:39] <tcole> yes
[00:40] <tcole> well, I'm amused
[00:40] <tcole> it seems the server currently uses even request IDs too :(
[00:41] <tcole> amused is the wrong word for what I am feeling
[00:41] <tcole> at least if I'm reading the code correctly
[00:44] <sladen> probably it doesn't matter as they're always used in one direction only
[00:45] <sladen> but if they do overlap that's most likely to affect debugging
[00:52] <tcole> yeah, thinking about it more
[00:52] <tcole> the way things are at the moment, it isn't likely to cause visible harm
[00:52] <tcole> but still should be fixed
[00:52] <tcole> I put in an ubunet bug
[00:52] <tcole> I think we're beyond changing it on the clients at this point
[00:53] <tcole> hm, I think that does it for me for tonight
[00:53] <tcole> I just pushed more updates to the README
[00:53] <tcole> probably look at getting that landed monday
[01:00]  * sladen bzr pulls
[01:08] <tcole> also fixed the comments in the actual code to match what the client does and the readme says
[01:14] <sladen> 00:29 < sladen> "# we are a client, we do odd requests"
[01:14] <sladen> 00:30 < sladen> would be clear to say   "odd numbered request IDs (eg. 1,3,5,...)" or something
[01:15] <sladen> oops
[02:06] <sladen> tcole: 'protoc' itself appears to actually be in 'protobuf-compiler'
[02:07] <tcole> hm, isn't that what I said in the readme?
[02:07] <tcole> that protoc was available via the protobuf-compiler package?
[02:07] <tcole> or did I word it confusingly?
[02:10] <sladen> 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] <BUGabundo1> you guys still at it?
[02:13] <BUGabundo1> lol
[02:22] <sladen> is/was 'idisk' a codename?
[02:22] <sladen> < 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] <tcole> idisk was never a codename for us that I'm aware of
[02:23] <tcole> and python-protobuf is a typo
[02:24] <tcole> or, well
[02:24] <tcole> need both python-protobuf and protobuf-compiler I guess
[02:26] <tcole> pushed fix
[02:31] <sladen> 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] <tcole> I don't understand the question.
[02:31] <sladen> tcole: eg. how does the server differientiate storage-protocol from email-protocol from foo-prtocol
[02:32] <tcole> different ports, at least
[02:32] <tcole> typically different servers on the backend as well
[02:32] <sladen> oh right.
[02:33] <sladen> I take it this doesn't work particulary well via HTTP proxy servers
[02:33] <sladen> so port 20100 is u1storage
[02:36] <tcole> actually, no
[02:36] <tcole> it does SSL on port 443
[02:37] <tcole>     parser.add_option("--port", dest="port", metavar="PORT",
[02:37] <tcole>                       default=443,
[02:37] <tcole>                       help="The port on which to connect to the server")
[02:37] <tcole>     parser.add_option("--host", dest="host", metavar="HOST",
[02:37] <tcole>                       default='fs-1.ubuntuone.com',
[02:37] <tcole>                       help="The server address")
[02:37] <tcole> actually we just have different servers
[02:37] <tcole> as long as the firewall allows https through it should allow this
[02:39] <sladen> is this an HTTPS channel (that happens to be on port 443)
[02:39] <tcole> just raw SSL, IIRC
[02:39] <sladen> or this a RAW TCP channel (that just ... okay
[02:43] <sladen> 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] <sladen> most interesting
[02:45] <sladen> so ubunet is not a monolithic app on a single machine
[02:45] <sladen> it's an app that happen to listen on one particular port on one particular machine and speak just one protocol
[02:45] <sladen> (ubut
[02:46] <sladen> 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] <tcole> well, lucio who will be here on Monday is the foremost expert on it
[02:47] <tcole> but we call it the "API server"
[02:47] <tcole> which is not really the most helpful/descriptive name
[02:47] <__lucio__> storage api server should be good enough
[02:48] <tcole> yes, though we shall have to distinguish file storage and structured storage eventually
[02:50] <sladen> __lucio__: is that what you actually called it when chatting over the coffee table?
[02:50] <sladen> s/called/call/
[02:50] <__lucio__> tcole: i imagine structure storage will go by the name of couch something
[02:51] <tcole> 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] <tcole> 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] <sladen> so "ubunet storage api server"
[02:55] <tcole> s/ubunet/ubuntu one/
[02:56] <sladen> no, "ubuntu one" is the this vague term that is causing alot of respentment, confusion and complication from being vague
[02:57] <sladen> 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] <sladen> that phrase is tarnished, it's useless as anything other than a marketing brand
[02:59] <sladen> (where being vague + all encompassing *is* the desired result)
[02:59] <sladen> it's the difference between   CLI, CLR, CTS, C# and ".Net"
[03:06] <sladen> 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] <sladen> __lucio__: mmm.
[03:09] <sladen> __lucio__: what's the actual binary running fs-1.ubuntu.com called?
[03:10] <tcole>  /usr/bin/python :)
[03:10] <__lucio__> sladen: canonical/ubuntuone/storage/server/server.py
[03:11] <sladen> crikey
[03:14] <tcole> maybe we should start giving things ikea names
[03:15] <sladen> I'm slightly amazed that names haven't developed on their own
[03:15] <tcole> it's a shame we couldn't legally use "hammertime"
[03:19] <sladen> eg. if I'm discussing a component in Launchpad I can succinctly refer to Malone/Soyuz/Rosetta
[03:21] <sladen> you just tweak it slightly;  eg.  hammermime
[03:24] <sladen> Suppose I could just do what that magazine did for the Spice Girls
[03:25] <sladen> make so up and see if they stick
[03:37] <lifeless> tammerhime?
[03:43] <rmcbride> Hammermime, now that would be something to see.
[03:43] <rmcbride> BTW, sladen thanks VERY much for your bug reports today
[03:43] <rmcbride> 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] <dobey> wow
[06:48] <platypus_> How can I get an invite to ubuntuone? currently using Dropbox just want to give ubuntuone a run
[11:01] <sladen> 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] <sladen> lifeless: yeah, 'hammerhime' would have the edge on pronoucnability
[12:06] <sladen> how is "storagefs" used in general conversation
[12:11] <sladen> __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] <sladen> __lucio__: don't tell me, that's called  canonical-ubuntuone-storage-server.sh  ...
[13:20] <sladen> o is there a web-based [D[D[D[D[D[D[D[D[D[D[D[B[B[B[B
[13:20] <sladen> is there a web-based interface to u1sync aswell?  (as part of ubunet and exposed by HTTPS?)
[13:20] <ceelight> Hi everybody! Is there a changelog or something that describes bugfixes ect. of new ubuntuone-client versions somewhere? thx!
[13:21] <sladen> https://bugs.edge.launchpad.net/ubuntuone-client/+bug/384065  seems to suggest that it does
[13:21] <sladen> if so, what is this called
[14:03] <dobey> 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] <sladen> dobey: okay.  Any idea what is referring to?
[14:05] <sladen> dobey: (the webbrowser reference)
[14:05] <dobey> 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] <dobey> sladen: https://ubuntuone.com/files/ <- web ui
[14:07] <sladen> 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] <dobey> sladen: it's a file browser view effectively similar to viewing ~/Ubuntu One/ in browser mode in nautilus, yes
[14:10] <sladen> dobey: and you can do upload/download operations equivalent to those undertaken by u1sync-agent
[14:10] <dobey> you can upload files and download files via the web, yes
[14:10] <sladen> dobey: and you can do upload/download operations equivalent to those (handed to the nautilaus extension) and undertaken by u1sync-agent
[14:11] <dobey> the nautilus extension doesn't do anything with files
[14:11] <dobey> it simply sets emblems based on status, and provides UI to share folders
[14:11] <dobey> and a button to connect/disconnect the service
[14:17] <dobey> sigh. palm pre has some ui issues :-(
[14:18] <dobey> and why the hell won't it log in to my mail server :-/
[14:35] <sladen> dobey: interestingly, that nautilus extensions won't have worked for anyone except on amd64 (or whatever arch the buildds are)
[14:40] <dobey> sladen: how do you figure?
[14:55] <dobey> sladen: the nautilus extension is currently in python... so it's architecture independent (the ubuntuone-client package is built for architecture all)
[14:55] <dobey> 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] <sladen> dobey: yeah, but that .so file is only being compiled as the architecture of the buildd in question.  (bug #384276)
[14:58] <sladen> it works on all platforms, but only if compiled for each (Architecture: _any_)
[14:58] <dobey> eh
[14:59] <sladen> basic computing 101, different processors have different instruction sets
[14:59] <sladen> i386 binaries do not run on powerpc
[14:59] <sladen> amd64 binaries do not run on sparc
[15:00] <sladen> arm binaries do not run on ia64
[15:01] <sladen> 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] <sladen> C libraries must be compiled for each processor type, and the result binary (and package) will only work on that processor type
[15:03] <dobey> i know how architectures work. thank you very much.
[15:05] <dobey> and there isn't an .so in the debian package
[15:07] <sladen> apologies if there isn't.  What is the file in  nautilus/ubuntuone-nautilus.c  compiled to?
[15:07] <dobey> it's not currently compiled by the package build
[15:07] <dobey> it's the in-process port of the extension to C
[15:09] <sladen> ah, so it's not used yet
[15:10] <dobey> right
[15:10] <sladen> The current code being  canonical/ubuntuone/nautilus/nautilus_api.py
[15:15] <sladen> what's "fsm" ?
[15:17] <dobey> file something manager
[15:17] <dobey> sladen: the current code being nautilus/storage.py actually
[15:22] <radix> finite state machine?
[15:26] <sladen> dobey: if an {email,calendar,...} client is written, would have use 'python-u1storage' ?
[15:26] <sladen> dobey: if an {email,calendar,...} client is written, would that use 'python-u1storage' ?
[15:26] <sladen> or what is have it's down low-level protocol
[15:26] <dobey> or maybe finite state machine
[15:27] <dobey> the 'structured storage' thing that we're going to release soon will use the couchdb protocol for replication
[15:28] <sladen> so that's won't share (any) code with the u1sync/u1storage stuff currently released?
[15:31] <sladen> the only thing in common is that that it falls under the same "Ubuntu One" high-level project name
[15:32] <dobey> 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
[15:32] <dobey> but ubuntuone-storage-protocol is the protocol for filesystem level storage stuff
[15:32] <dobey> ie, the "this is for storing files, not simple text records like contacts/events"
[15:33] <dobey> hrmm, i wonder if i can theme the palm pre
[15:33] <dobey> probably requires mucking about with the firmware though :(
[15:35] <sladen> 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] <sladen> 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] <sladen> I think I confused even myself in writing those two lines
[15:37] <sladen> I'll go and read the code again and try to guess
[15:40] <sladen> ...
[15:41] <sladen> dobey: does the http://ubuntuone.com/files/ work with directories uploaded using the u1sync commandline/ftp tool (not the u1sync-agent)
[15:42] <dobey> 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] <sladen> 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] <BUGabundo> sladen: not now
[15:54] <dobey> palm pre is sexy, but i really don't want all of my aim/facebook/etc contacts to show up everywhere :(
[15:54] <BUGabundo> on an Assembly
[16:04] <__lucio__> sladen: i thin its called /etc/init.d/ubuntuoneapiserver
[16:48] <dobey> later
[16:49] <BUGabundo> dobey: later
[16:52] <artir> BUGabundo: later
[16:53] <BUGabundo> artir: I'm staying
[16:53] <BUGabundo> lol
[16:53] <artir> I didn't saw the dobey:
[16:53] <artir> xd
[17:14] <sladen> __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] <sladen> __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] <sladen> can somebody remove the Milestone on  https://bugs.launchpad.net/ubuntuone-client/+bug/377346  and repoint it at the server-end (ubunet)
[17:27] <sladen> it doesn't relate to the client software at all
[17:36] <sladen> with regspect to oauthenciation, what do  'rtu', 'uau', 'atu' refer to?  I'm presuming the 't' is '-to-'
[17:39] <sladen> 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
[18:29] <sladen> __lucio__: what/who is "ISD" ?
[18:59] <sladen> rmcbride: regarding 100meg.file  etc, is it really that big?
[18:59] <sladen> rmcbride: and for things like the JPGs, what's the license of those?