=== thekorn_ is now known as thekorn [08:50] !connection [08:50] Sorry, I don't know anything about connection === statik` is now known as statik === tcole1 is now known as tcole [14:41] Good morning [14:41] how's everyone doing today? [14:46] \o/ [15:06] pretty quiet in here [15:07] everyone still waiting on invites? [15:07] invite processing should speed up soon, but at present we're still turning the crank very slowly [15:07] trying to avoid scaling too quickly and being the next twitter :) === yofel_ is now known as yofel [15:22] invite? [15:22] invitations, for the service [15:22] oh i didnt think it was needed. Unless the email i got was the invite when it first surfaced [15:26] * artir wants access to the API :) [15:28] which API did you have in mind? [15:30] (is what you're looking for not available in the ubuntuone-client package?) [15:47] i want to do something like [15:47] import ubuntuone [15:48] and after init sth, do self=ubuntuone.get_items() [15:48] print self [15:48] or stuff like that [15:48] or ubuntuone.push("/home/lol/cheese.png") [15:55] i like that you have a user named lol [15:55] of course [15:55] who doesn't? :P [15:56] o/ === kklimonda_ is now known as kklimonda [16:00] greg-g: check your /home [16:00] there is a hidden lol user put there by canonical [16:01] nobody can see it, not even root [16:01] it's part of their plan to take over the world, nothing bad at all :) [16:01] artir: then how am I supposed to find it? :) [16:02] you can't mwahahaha [16:03] so really a simplified wrapper API on top of the raw API [16:04] canonical will probably release it for the OSCON conference [16:04] it think [16:04] release what? [16:10] uhm. well [16:10] ubuntuone-storage-protocol /is/ that api [16:11] there will be additional APIs for new services as they are necessary and added, though [16:12] well, it isn't really [16:12] it's not that easy to use [16:12] but it is the raw API [16:13] well, it's not trivial. but ubuntuone.push() could mean a vast number of things for ubuntu one. (and i don't see how for the storage service, it would be any different than just moving a file into the My Files directory) [16:14] that assumes you can run the syncdaemon, or want to [16:15] anyway, anyone can use the API we have now [16:15] but I do maintain that it needs a nicer wrapper on it so it is easier to use [16:17] i really wish fuse wasn't awful [16:18] indeed [16:18] boxbot is terrible [16:19] what is boxbot? [16:21] nobody likes boxbot [16:21] http://www.gunnerkrigg.com/archive_page.php?comicID=205 === thekorn_ is now known as thekorn [18:55] I see we have an unshare feature \o/ [18:55] thank you guys! [18:59] we're slowly getting there :) [19:00] (and you're welcome) === ursula_ is now known as Ursinha [20:41] wii #ubuntuone [20:42] Could somebody assist me in getting a general overview of u1 and how it fits together [20:42] The first thing I'm after are the clear names for the separate componets/layers [20:43] Rather than just "Ubuntu One" [20:47] hm [20:47] well [20:47] Ubuntu One is destined to be a suite of services [20:47] the only one currently on offer is the dropbox-like file storage + sharing [20:47] but more are in development [20:47] for the storage service in particular [20:48] i think he's looking for clear definition between "suite of services" and "what those services are" [20:48] ie, during the CC meeting, there was lots of confused discussion about "what is the platform" and "what are the services" [20:48] because they are all "Ubuntu One" [20:48] hm, I'm not even sure how to answer that really [20:49] there are several different ways to categorize things depending on what perspective you're coming from [20:50] I mean, as a developer, I know how I'd split up the components/layers [20:50] but that may not be what you're asking? [20:50] guud evening [20:51] hi BUGabundo [20:51] BUGabundo: i got the weight conversion backwards. the u820 is about 0.8KG [20:51] Kg even [20:52] you know [20:52] tcole: dobey: okay, so you specifically mentioned the dropbox-like functionality. When you're drinking coffee next to the water cooling, how do you verbally refer to that 'corner' [20:52] I read it on identica, and already knew you were wrong [20:52] lol [20:52] sladen: storage [20:52] sladen: 'storage' [20:53] BUGabundo: i just got it backwards, but eh [20:53] what a boring name. (Thank you for the clear answer though). [20:54] the code name was hammertime [20:54] tcole: that's precisely the answer I'm looking for [20:54] we don't call it that now though [20:54] well, storage is storage [20:54] I'm just waiting for the *extra* features [20:55] if we implemented chat, we'd call it chat, not storage :) [20:55] right now, I don't see U1 being more then a poor Dropbox clone [20:55] it helps to have an arbitary term to refer to 'X' that is not 'X' and therefore would not occur in general conversation when talking the generic implemetnation of Xs [20:56] well, it's 'ubuntu one storage' then [20:56] BUGabundo: I don't. But such confusion occurs when there is only one application, one protocol, one server and one implementatino of each of those [20:56] dropbox works ok as 'dropbox' because they only do one service [20:56] yep [20:56] and they do it darn *good* [20:56] we actually used to have the opposite problem with Launchpad [20:56] we gave everything individual product names [20:56] of course they have been longer doing it [20:57] and i remember everyone used to call 'evolution' "ximian" :( [20:57] and then nobody knew what things were [20:57] so eventually it just became Launchpad code, Launchpad bugs, etc... [20:57] BUGabundo: if you think back to the introduction of "remixes" for Ubuntu diverivatives, lots of people (journalists) got confused and saw 'remix' as the brandname for the first example (Netbook _Remix_) because there was only one [20:58] tcole: dobey: I've filed several bugs at https://launchpad.net/ubunet/ because that's where I came across the first bug report [20:58] which "bit" is 'ubunet' [20:59] that's a private project for backend stuff basically [20:59] sladen: yeah I remember that [20:59] ubunet is the server and is only temporarily ubunet. we'll be renaming it soon [20:59] any user-visible things are associated with ubuntuone-client, including the web UI [20:59] but ppl do mixed up OS with Distro too... but that OT here [20:59] tcole: so ubunet is the implementation of a $something server [20:59] well, no [20:59] BUGabundo: yes, people just say 'that linux thang' and have no idea which distro they mean [20:59] sladen: I have the same prob! I'm not sure what is what, and where to file bug for each [21:00] it's really a blanket for all the backend stuff for all the services [21:00] dobey: they say "that DOS thingy" [21:00] tcole: is ubunet the project? [21:00] * BUGabundo we need a *good* FAQ [21:00] BUGabundo: mostly i just see people say 'microsoft' when referring to any product of theirs [21:00] sladen: ubunet was the "we need to start working on this, call it something until the Name is Decided" [21:00] BUGabundo: FAQs don't help because nobody actually reads them. [21:01] BUGabundo: yeah, it's been 2.5 weeks, so that's what I'm trying to undertake in a roundabout way. Which is why I'm in here asking dumb(tm) questions [21:01] sladen: ubuntuone is the project. it is the parent project for all the related projects [21:01] or Windows! anything is windows... oh and Internet is IE.... just lan or any app using the "internet" is not net! :\\ [21:01] sladen: ie, http://launchpad.net/ubuntuone [21:01] dobey: 3rd thing I read.... [21:01] 1st is site look, 2nd about, 3rd FAQ [21:02] BUGabundo: well, yes. you. but 1/6bln isn't very much :) [21:02] sladen: no question is dumb... only answers [21:02] dobey: ehehehh [21:03] brb, need to reboot... hal has gone crazy again and won't open the pod bay doors [21:03] dobey: tcole: so (although it does contradict the statement above), 'ubunet' is what I would have to replicate if I wished to use a completely Free stack [21:03] mieszkoslusarczyk: Pity there is no kde client for ubuntuone. [21:03] mieszkoslusarczyk: But I think It'll be easier to create one for ubuntuone;) [21:04] dobey: tcole: eg. everything that is internal/proprietary is contained with the perimeter of 'ubunet' [21:05] dobey: tcole: or perhaps another way to phrase that. What is the command that is run to start a daemon listening for incoming $somthing requests [21:05] sladen: ubunet corresponds pretty well to the proprietary bits [21:06] in terms of LP projects, ubuntuone is the umbrella project, with ubunet, ubuntuone-client and ubuntuone-storage-protocol as subprojects [21:06] BUGabundo: if I understand it, There is _not_ a GNOME client for 'storage' (hammertime?), there is a _Nautilus_ client [21:07] no, not really [21:07] BUGabundo: and there could be a fuse client, etc? [21:07] the client is just a user daemon which watches a folder [21:07] it exposes a dbus interface which a nautilus extension interacts with [21:07] but you don't need to run nautilus to use it [21:07] (there are some Gnome dependencies like gnome-keyring at the moment though) [21:08] we actually did implement a fuse client [21:08] it was a disaster [21:08] tcole: aah [21:08] why ? [21:08] tcole: that's good to know, it demonstrates it's not quite single-implemtnation [21:08] several different reasons, but performance and stability [21:08] sladen: in addition to the syncdaemon, we do also ship a very simple/stupid commandline client [21:09] which bit(s) in the current stack was "the fuse client" equivalent to? [21:09] sladen: which works a bit differently than the daemon [21:09] the syncdaemon replaced the fuse client [21:09] tcole: funky, hadn't spotted that (I'm trying to analyse this without actually being able to use it---I can't agree to the T&C for the beta) [21:10] anyway, the two clients we currently ship are the syncdaemon and u1sync [21:10] i don't know that i would call syncdaemon and fuse filesystem equivilent [21:10] sladen: you should be able to grab the packages/source from the ubuntuone-client project without worrying about the beta T&C [21:10] did it have a name at the time it existed/was a disaster [21:10] sladen: those bits are simply AGPL, IIRC [21:10] sladen: storagefs [21:10] tcole: yeah, those bits are fine/clean/etc [21:11] sladen: well, ubuntuone-storagefs; we didn't want to pollute the fs name namespace [21:11] sladen: but we just called it "storagefs" [21:11] sladen: you can tell we are very creative with names :) [21:12] the generic names (to me with my developer mind) make it quite hard to know what the scope is [21:12] 4 more invites sent! I'm rolling tonight [21:12] it's like trying to hammer home "Ubuntu 9.10"... people don't, they refer to Karmic [21:12] the scope of a storagefs is not contacts... seems pretty simple to me :) storage == storage [21:12] * BUGabundo calls 8.10 ibex... interpid is just too long [21:13] dobey: so it's actually u1-plugin-storage and u1-plugin-storage-nautilus ? [21:13] we don't have plug-ins no [21:14] well the nautilus bits are a nautilus extension, so that's a plug-in to nautilus [21:14] stoage is an /optional/ addition to the $something API/database/wire setup? [21:14] storage is a service which you may optionally subscribe to [21:15] 'storage' is a service which presents a DBus API on one side, and which does magic $something on the other? [21:15] there's not really any other api/db/wire bits at the moment [21:15] sladen: it's not magic. it uses ubuntuone-storage-protocol which is AGPLv3 [21:16] sladen: it uses google protocol buffers to implement the wire protocol for storage [21:16] woohoo! [21:16] let me go and research what those are [21:17] the dbus API is just for controlling the syncdaemon [21:17] the syncdaemon itself is the actual client [21:17] and of course u1sync is the other client we ship [21:17] dobey: optionally? but rigt now U1 is just that: storage [21:17] that will change [21:17] BUGabundo: yes, and it is optional [21:18] I mean, we will have more than just storage [21:18] BUGabundo: you are in no way obligated to subscribe to the storage service [21:18] google protocol buffers ? 1st time I heard that [21:18] tcole: I know that! if you read a bit back, I said im waiting on the rest! [21:18] http://code.google.com/apis/protocolbuffers/docs/overview.html <-- for anyone listening to the scroll [21:18] dobey: so currently what would I have wihtout storage? [21:19] BUGabundo: an account that doesn't do anything for you :) [21:19] ahahaha [21:19] BUGabundo: assuming you log in to ubuntuone.com anyway [21:19] yeah that's what I though [21:19] tcole: dobey so what is the timeframe for the so mentioned changes? [21:19] sladen: something we need to do soon is document the *semantics* of the protocol buffer messages; at present you pretty much have to look at one of the existing open source clients to see that [21:20] BUGabundo: but it's still entirely optional, whether or not it actually provides any utility to you :) [21:20] dobey: :) [21:21] tcole: yeah, we're getting to the stage where I can go and read the code effectively without banging my head against a wall wanting a high-level overview [21:21] I'd probably say that u1sync is easier to understand than syncdaemon [21:21] though I'm a little nervous saying that [21:22] because u1sync is something I basically threw together over a weekend [21:22] not great code [21:23] dobey: tcole: so the wire-protocol is application specific Google protocol serialisations updating an object database using REST over HTTPS? [21:23] minus the REST part [21:23] tcole: next time, write two demo clients, it's solve 95% of the confusion ;-) [21:24] LOL [21:24] tcole: since you'll be forced to give them different names otherwise they both won't compile! [21:24] in all seriousness, I may do more, time permitting [21:24] but not for that reason [21:25] joking aside, it's not REST. Are the references to REST that is is RESTful in style? [21:25] tcole: u1sync is the command lline tool (correct) [21:25] ? [21:26] correct [21:26] I'm not sure where the REST references are coming from [21:26] the storage protocol is fairly stateful [21:27] now [21:27] we do have a "structured storage" thing in progress [21:27] what REST references? [21:27] which is based on CouchDB [21:27] and that does do RESTy things [21:27] but that is distinct from "file storage" [21:27] which is what we have out there now [21:30] dobey: no idea, I've come across them somewhere. [21:30] dobey: probably Chinese whispers [21:31] and CoudchDB is this thing that requires installing 45MB of erlang [21:31] yep [21:31] needless to say that didn't fly very well with the distro folks, who are rather scarce for space on the CD :) [21:31] so we are working on fixing that whole 45MB of erlang part if we can [21:32] I am not closely involved with that part of things though [21:34] tcole: CouchDB is talked to over a JSON/HTTP interface. What is it that is doing the talking? [21:35] I think it's a CouchDB running locally [21:35] I presume there's an instance of CouchDB running (once?) per machine and once again one the server end [21:35] but I don't work on that service right now, and it hasn't been released yet [21:35] something along those lines [21:36] confused. is CouchDB actually in use at this point in time? [21:36] not in ubuntuone yet [21:36] if it's not, I can completely ignore as it doesn't reflect what's there at the moment, only vague future vapourware [21:36] and it will be couchdb-per-user [21:42] ok now you guys went to a too geeky point [21:42] I can't keep up [21:43] :) [21:50] sladen: right, vapourware and lies :) [21:53] heh [21:56] sladen: u1sdtool is also the command line tool [21:56] sladen: in fact, I wouldn't call u1sync the commandline tool :) [21:56] u1sdtool is a CLI way to interact with syncdaemon via dbus [21:56] it is a commandline tool [21:56] yes [21:56] but it is not a commandline client [21:56] syncdaemon and u1sync are the two clients [21:56] right [21:57] sorry if I read the wrong half of the conversation :) [22:01] u1sync is the commandline sync client; u1sdtool is the commandline control interface. syncdaemon is the daemon? [22:01] which is the nautilus plugin client? [22:02] syncdaemon doesn't have anything to do with nautilus [22:02] although there is a nautilus extension which can talk to it [22:02] which is the nautilus _extension_ that can talk to syncdaemon [22:02] u1sync is a minimal commandline client, syncdaemon is a full-featured client which runs as a background daemon [22:03] oh [22:03] clients of *what*? [22:03] u1sdtool is a commandline control interface for syncdaemon, there is also a gnome panel applet which controls syncdaemon, as well as a nautilus extension [22:03] the storage service [22:03] file storage service [22:03] tcole: aren't you tired of exlaing it over and over? [22:03] write a FAQ instead [22:03] eheh [22:03] BUGabundo: I'm trying. [22:04] sladen's already doing that, which is why he's asking me [22:05] ahhhhhhhhhhhhh [22:05] great [22:05] not that I have an objection to writing a FAQ myself, but seeing as he's already started [22:05] I won't steal his thunder :) [22:06] BUGabundo: since that's the only way myself and other people are going to understand "it". Understanding "it" (and being able to effectively talk and point and the specific areas) is hopefully the stepping stone to enabling proper discussion about any wider issues [22:06] humm [22:06] this will be a _nice_ FAQ long [22:06] from a POV of a user [22:06] lots of user assumptions [22:10] so u1tool == ncftp and syncdaemon == rsync. Both connect straight out to someserver.ubuntuone.com without passing Go! and without collecting 200 GBP [22:10] hm, not really quite [22:10] u1sync is a little bit like s3sync [22:10] syncdaemon is like the dropbox daemon [22:11] they both connect to (right now) fs-1.ubuntuone.com [22:11] and speak the protocol defined by the stuff in the ubuntuone-storage-protocol package [22:12] u1sdtool, the gnome panel applet, and the nautilus extension are just control interfaces for syncdaemon [22:12] does that make sense? [22:13] will you be putting the FAQ on the Ubuntu wiki? [22:13] we have a page here already which is rather unenlightening -> https://wiki.ubuntu.com/UbuntuOne [22:13] http://s3.amazonaws.com/ServEdge_pub/s3sync/README.txt <-- for anyone following the scroll [22:14] u1sync is a little different to s3sync in several respects, one of them is that you have a separate "init" step, a bit like "bzr init" or something [22:14] basically associating a local directory with some directory tree on the server [22:14] after which u1sync in that directory does a sync without needing any arguments [22:14] and that relationship is recorded by a hidden file/uuid linking those? [22:15] yep [22:15] cunning guess. What's the name of this file? [22:15] well, it's a directory [22:15] .ubuntuone-sync [22:15] so the directory is called 12341234-1234-1234-a-ba-234? [22:16] the directory has a number of individual files under it [22:16] which contain things like the root UUID, the path, and so on, of the subtree you are mirroring [22:16] So at the moment, a user ends up with ~/Desktop/Ubuntu One/{myfile{1,2,3},.ubuntu-sync/*} [22:17] no, the syncdaemon operates very differently [22:17] u1sync is basically for "checking out" a copy of your files in a place separate from where the syncdaemon works (or would work -- you can opt not to use it) [22:17] so that _one_ instance of '.ubuntuone-sync/' lives at ~/.ubuntuone-sync/ [22:17] tcole: dobey: so what is the timeline for the so called new _features_ other then storage? [22:17] nope [22:17] BUGabundo: when they're ready. :) [22:17] come on!! [22:18] BUGabundo: shhhh. [22:18] u1sync puts .ubuntuone-sync in a the directory you initialized for use with it [22:18] don't do that to me again [22:18] BUGabundo: but we are working on them to get stuff deployed asap, because there are things we want working in karmic [22:18] we don't really like to go into details about unreleased stuff becuase it confuses people (as sladen rightly pointed out) [22:18] u1sync behaves sort of like a vcs in respect to how it functions [22:18] and also until it's actually released and people have the client source code it's all lies anyway :) [22:18] tcole: I can't confuse me [22:18] AHAHAH [22:19] I'm an alpha tester [22:19] sladen: .ubuntuone-sync is a lot like the .bzr directory that bzr creates in a checked-out tree [22:19] I run cutting edge on anything, and am more the used to stuff changing without notice [22:19] sladen: the syncdaemon works very differently, and keeps all its metadata under ~/.cache/ubuntuone [22:20] so stuff checked out with u1sync is not compatible with syncdaemon (I would instead have to use u1sdtool to direct syncdaemon to undertake the action(s)) [22:21] * BUGabundo is being ignored .... [22:21] sladen: that's the simple version yes [22:21] u1sync is roughly bzr init || bzr clone || bzr push [22:22] s/||/xor/ [22:22] sladen: kind of [22:23] BUGabundo: okay, I'll ask you a couple of question as you've got more hands on experience than me [22:23] BUGabundo: can you describe what "Ubuntu One" is in less than 10 words [22:23] BUGabundo: I'm trying not to ignore anyone, but I'm not sure what else to say and I have limited brain [22:23] BUGabundo: because I can't, yet [22:24] ok sladen [22:24] best I can do: Ubuntu One is online services. Just file storage to start. [22:24] (10 words) [22:24] sladen: i can, but i don't think you'll accept my ingenuity with it :) [22:25] U1 is a Cloud implementation, providing right now Free and Paid Online Storage, to Ubuntu GNU/Linux Distro [22:25] I think maybe cloud is misleading [22:25] dobey: please tell us [22:25] BUGabundo: it's at least 14 words ;) [22:25] cloud is a silly buzzword [22:25] because then people start imagining we're offering an EC2 clone or something [22:25] BUGabundo: 1 word: awesome [22:25] BUGabundo: what's a cloud? [22:25] :) [22:25] (which I keep getting asked about!) [22:25] dobey: I know. that's why I used it [22:25] its like Web 2.0 duh [22:25] sladen: the giant grey things hovering over my city at the moment [22:26] dobey: LOL [22:26] sladen: providing web services for data [22:26] hm [22:26] dobey: duded, I didn't realise those bits had names, I thought it was all just "One Sky" ;-) [22:26] cloud has nothing to do with services [22:26] have we ever said anything about web services? [22:26] in this entire discussion? [22:26] cloud is just a stupid term that means "internet" [22:27] sladen: dobey: isn't that on cities: SM>OG? [22:27] *SMOG [22:27] well, maybe "abstracted server farm over the internet" [22:27] but a lot of people do just mean "vaguely internet somehow" by it [22:27] BUGabundo: smog doesn't produce rain. it just produces bad air [22:27] dobey: Cloud: is Remote... no need for internet [22:27] actually smog particles can nucleate raindrops [22:27] tcole: do they breed new servers on this farm? ;) [22:28] sure [22:28] we have an entire division at Canonical dedicated to server husbandry [22:28] I'm hoping it's a "remote-access secure object storage database" [22:29] I'm hoping it's a "remote-access secure object storage database over Google buffers" [22:29] what we currently offer is file-based rather than object-based [22:29] at least as an abstraction [22:29] anyway. I don't think anyway succedded. nil point all around [22:29] the implementation behind the scenes looks a bit different [22:30] tcole: come on... raise the curfue a bit, and let me know what you guys have in store [22:30] tcole: ooooh. So the far end is nothing more than an directory and you could run the rest over FTP, or WebDav? [22:30] BUGabundo: I doubt they know. [22:30] FF intregration? mail intregration (does anyone need that?), contacts ? [22:30] sladen: it's (sadly?) more complicated than that by far [22:31] sladen: but we have discussed the possibility of offering a WebDAV view into the storage [22:31] tcole: it's more complicated because it's versioned? [22:31] BUGabundo: first we need a decent mail client ;} [22:31] tcole: or because it's abstracted [22:31] tcole: or because it's structured? [22:31] versioning will be an issue eventually [22:32] but that's not something we expose right now [22:32] what makes (at this point in time) it more complicated than an FTP directory? [22:32] sladen: Versinaged!!?!!?!?!?! [22:32] principally the sharing stuff [22:32] KEYWORD alert! [22:32] BUGabundo: relax man [22:32] damn ... "eventually" [22:33] dobey: :)) [22:34] tcole: with regard to the platform only (not any storage/syncdaemons running over the top), what makes the platform more complicate than an FTP directory with ACLs [22:34] from whose point of view? [22:34] I guess one major difference is push notifications of changes [22:35] when a client connects, you are given the UUID of the root node of your storage, as well as the roots of any shares available to you [22:35] tcole: so at the start of the session, I login, subscribe to a bunch of stuff, and then get proactively poked when something gets updated (which if there is only one user accessing at a time, means never) [22:35] yes, that's about right [22:36] minus the subscription part [22:36] you get poked about anything you have access to [22:36]