[00:01] Is file storage the only planned feature in the karmic timeframe? [00:03] no [00:04] Ooh. Are other details available yet? [00:05] some things were discussed at UDS, yes [00:06] Hrm. I'll have to dig around, then. [00:06] the big thing being the 'structured storage' stuff (horribly confusing name that is) [00:06] Structured storage? [00:06] i think there are some blueprints for it [00:07] syncing and storage of contacts for example, with the ability to replicate your contacts to other PCs on your LAN easily [00:08] ok, quick yes/no question: Does U1 sync folders that are symlinks to a folder outside of ~/Ubuntu One (it appears it is not syncing that right now) [00:08] greg-g: no, it doesn't. [00:08] nhaines: thanks. [00:08] i think we ignore symlinks because doing The Right Thing (TM) with them is insanely difficult [00:08] greg-g: no prob. Best way is to do it the other way around: symlinks *into* ~Ubuntu One [00:09] I remember hearing a bit about integrated contacts but I thught it was further off. [00:09] nhaines: yeah, right now that is all set up in my ~/Dropbox folder. I was hoping I could just make one newsymlink instead of updating many old ones :) [00:09] we're trying to do as much as we can, as fast as we can [00:10] dobey: makes sense [00:10] dobey: frankly, I thought cloud file synchronization was pretty compelling by itself. [00:10] On the other hand, I'm looking forward to other projected features such as screen sharing. [00:11] the most compelling feature is the desktop integration, really [00:12] although, i really wish i had the Pre SDK right now [00:15] Does desktop integration refer to the client and the Nautilus extensions? [00:16] currently, that is what we have, yes [00:17] but moreso, it refers to things we'll hopefully be doing in the relatively near future :) [00:20] anyway, must go now... later [00:24] dobey: later. :) [03:32] Thanks to all the developers for the update on the website for removing shares !!! \o/ [03:33] VK7HSE: :) [03:35] heh [03:36] dobey: I just read the update from twitter !!! [03:38] ah [03:38] i blame jblount [03:39] dobey: I'm guessing you're right. I'm also sneaking people in the back door on twitter. [03:39] that's something you'll have to discuss with your wife, not me [03:40] dobey: ZOMGROFLMAO!@$! [03:40] :-/ (lol) [03:41] heh [03:59] oi. must get some sleep === jamesh_ is now known as jamesh [08:30] <[Puck]> hi everyone [10:27] dobey: say "Your openID" and "View your subscriptions" [10:28] greg-g: swap the directory and the symlink around [15:35] dobey: __lucio__: tcole: Comments about scope (rather than naming) are welcomed at https://wiki.ubuntu.com/UbuntuOne#Technical%20details (SteveA has already approached me with a few changes/suggestions) [15:35] <__lucio__> sladen: hi, good morning. looking now. [15:36] <__lucio__> sladen: re updown. updown server is not the web app, is the service that just handles the uploads and downloads. just that. gets and puts. [15:36] <__lucio__> (ive seen a web ui bug tagged updown) [15:38] __lucio__: yeah, stevea mentiond that too. [15:39] __lucio__: does storagefsd also talk to updown ? [15:40] <__lucio__> sladen: no, they just share some code [15:40] oh, hold on. Is the uploading and downloading out of band from the u1storage protocol channel [15:40] <__lucio__> sladen: only for web [15:41] __lucio__: so when you upload using the web, the page is served by a machine in the canonical datacentre, but the file itself comes directly from fs-1.ubuntuone.com ? [15:42] <__lucio__> sladen: no. syncdaemon talks with the api server. for everything. the web browser talks to the web ui server and the updown server [15:43] <__lucio__> just to make sure i dont misname things, i kept the names i know [15:46] and the instance of updown runs on the same macine as the instance of the ubuntuone-file-storage-api-server [15:47] and the instance of unamed-serivce-at-www.ubuntuone.com/files is on a separate machine (in the Canonical datacentre IP address space) [15:48] <__lucio__> sladen: i dont think they run on the same machine, no. [15:50] okay, but the unamed-serivce-at-www.ubuntuone.com/files is on a separate machine to the instance of updown [15:50] <__lucio__> sladen: again, im not sure, but i think it is. [15:50] is there a better name for "the unamed-serivce-at-www.ubuntuone.com/files" [15:51] no, updown runs on separate machines [15:51] from api, I mean [15:53] sladen: better name than? [15:53] Chipaca: nod. Is there a name/term for the front end part of www.ubuntuone.com specifically related to the "Ubuntu One Storage" [15:53] sladen: it is the web ui for file storage service [15:54] web ui. k. [15:54] sladen: webui :) [16:01] Hi all [16:02] <__lucio__> facundobatista: hey! welcome back! youre late :P [16:02] __lucio__, indeed [16:02] <__lucio__> facundobatista: when did you arrive? how was it? [16:03] __lucio__, a few hours ago... the plane landed with fog, too much fog [16:20] hello world [16:25] Hi statik [16:26] hola === chs is now known as chris17 === kklimonda_ is now known as kklimonda [17:37] tcole: I clashed with you splitting updown and webui. Which of those does webstorage correspond to? [17:40] ah [17:40] webui [17:40] updown is barely a user-visible thing [17:50] tcole: what's the name of the server that 'updown' runs on? [17:50] eg. something-1.ubuntuone.com [17:52] tcole: yeah, storagfs, u1storage, u1sync-agent .... they're all non-user visible. But that doesn't mean they're not equal parts of the jigsaw [17:53] that's actually a good question [17:53] * tcole checks [17:53] updown.ubuntuone.com [17:59] tcole: can yu check that https://wiki.ubuntu.com/UbuntuOne?action=diff&rev2=17&rev1=15 is correct [17:59] hi sladen, i just noticed on your website a link about british sign language, thats intriguing! i am fluent in american sign language but have never learned BSL [18:01] sladen: yes, that's just about right [18:01] statik: oh it's difference, we need both hands to spell the alphabet :) [18:01] sladen: updown is quite simple, it just checks access permissions in the database and basically does passthru to S3 as you describe [18:02] have we got a better way to phrase "It is possible to share a view (called a "Share") to a particular subtree to one or more individual users on a read-only or a read-write basis." so that it includes the word "directory" [18:03] sladen: hmm, not sure. it is important that shares are understood to apply to an entire subtree rooted at the shared directory, not simply the shared directory itself [18:03] it introducs too many concepts ("view" "share" "subtree") in the same sentence without giving them familiar equivalents [18:04] maybe I'll try to introduce that at the top. When you mirror stuff, you can choose to just mirror a sub-tree [18:04] and read-only is basically one-way mirroring [18:06] that sounds good [18:06] while it isn't terribly important to most users, that fits well with the way u1sync works, too [18:08] that's simple commandline/vcs/ftp-like tool? [18:08] yes [18:08] <__lucio__> mmh. not so much as ftp but maybe rsync. [18:09] it lives somewhere between bzr and rsync I think [18:09] <__lucio__> yes [18:10] under a bridge. and it demands payment for passage when you approach it [18:11] no, that's u1troll [18:11] for our previously unannounced automated trolling service [18:12] it's a bit like Amazon's Mechanical Turk, only focused on serving the Internet trolling community [18:13] *crickets* [18:13] (well, the joke seemed funny at the time...) [18:13] <__lucio__> we are going to leave so many people with nothing to do that its going to be amazing. a bit dangerous tough. [18:14] well, it's more about giving them an opportunity to monetize their trolling skills [18:16] when I add a new version of a file, that creates a new object, and a reference is also inserted into a directory object, [18:16] hm, not precisely [18:16] now, do each of the directory objects further up the chain, right the way to the top of the Share get updated too [18:16] no [18:17] new versions of a file are (at least in theory) the same object [18:17] pointing to a different blob? [18:17] yes [18:17] okay. So how do you find out what to re-mirror [18:17] though if the rename+create done by text editors and the like gets propagated to the server, obviously that ends up being a new object [18:17] I forget offhand whether we filter such rename + creates out at the moment or not [18:18] sladen: from the POV of clients talking the storage protocol, they get push notifications when particular nodes change [18:18] is any history kept, or is it the blob reference just overwritten straight [18:18] lucio: does syncdaemon transfer file identity on rename+replace yet? [18:19] right now it's overwritten, though that will change [18:19] well, it'll still be overwritten [18:19] but there will be a log alongside [18:19] maintaining history [18:19] tcole: so if I connect and in between, 20 objects were updates, the client gets 20 notifcations delivered at once? [18:19] sladen: when you connect, the client is responsible for spidering the tree and identifying changes on its own [18:20] sladen: since the server doesn't (can't, really..) keep track of "what you missed since you last connected" [18:20] a fully content-aware tree would make this easier (since you could trivially prune subtrees which haven't changed to avoid having to rescan them), but that isn't the current design [18:21] the push notifications are just for changes since the client connected [18:21] Ah, so the unsolicated push notifications are merely a convenience feature. They aren't actually essential to the operation [18:21] convience/optimisation [18:22] more or less [18:22] clients could poll but that would be pretty slow [18:22] u1sync doesn't bother with the push notifications since it's more of a one-shot deal [18:23] rather than something which stays connected persistently [18:23] __lucio__: ping [18:24] <__lucio__> tcole: here [18:25] __lucio__: did we ever do that thing in syncdaemon with recognizing text editor moves/renames when updating files? [18:25] it doesn't matter terribly now, but we're going to care about it when we implement history [18:25] <__lucio__> tcole: nope. i want to do that of not uploading open files. but never did [18:26] not uploading open files is something distinct [18:26] <__lucio__> tcole: i think will have to do something about it when we do history [18:26] yes [18:57] tcole: what about 'u1r' it sort of rhymes with 'bee-zed-arr' [18:57] for what? [18:58] tcole: the commandline one-shot tool that you are likely to need to type repetively [18:58] u1sync seems fine to me [18:58] the name 'u1ftp' I've given it at the moment is not quite right [18:59] definitely not [18:59] well, from my point of view [18:59] and u1sync is confusing as it is separate from/incompatible with the the rest of the u1sync infrastructure [18:59] u1sync is the one component with a specific, short name [19:00] https://wiki.ubuntu.com/UbuntuOne#General%20concepts [19:01] I'm not renaming the program :P [19:02] yeah... [19:02] I think for clarity, I'll rename it in the doc though [19:03] I'm not sure that will bring clarity [19:03] people will be looking for a u1ftp command or whatever [19:03] how does having the same name as something unrelated help? [19:03] it didn't until you gave something else a colliding name [19:04] I appreciate what you're doing [19:04] but I'm concerned by the lack of correspondence between what things are actually called and what you're calling them in the FQ [19:04] er, FAQ [19:06] Duely noted [19:06] yeah, i don't understand why you want to rename things in the FAQ [19:06] it's not really a fitting thing for documentation to do [19:07] I think it would be best, if you're giving things alternate names [19:07] to make it clear that the names are alternate names by using spaces and titlecase [19:07] rather than making them look like program names [19:07] and then mentioning the actual program names in the relevant sections [19:07] rather than leaving it for a table at the end [19:09] To take "ubuntuoneapiserver" as an example. "Ubuntu one" is a brand name that has nothing to do with file-sharing. The "API" is actually in an misnamed other python library, and "Server" is a generic name, (eg. the machine its running on). Nothing in there stated *anything* to do with filehandling or storage. It's confusing to somebody who is not familar with the project [19:09] I have less objection to renaming that [19:10] but when you call the user-visible program u1sync u1r or u1ftp or something else in the documentation, and it's really actually called u1sync, and u1sync is the command a user runs [19:10] there's a big disconnect there between the documentation and the actual user view [19:11] and if you're calling it that because you've already called something else u1sync ... maybe you shouldn't be doing that [19:11] we do need to give users names to call things [19:12] but what we don't want to do is create an extra layer of indirection [19:12] between the documentation and the user-visible system [19:12] okay, got an alternative suggestion for 'u1sync' (IIRC, I found the term "u1sync" used in components of the agent and its tool/applet. But I could be wrong [19:13] any of the code under canonical.ubuntuone.storage.u1sync is specific to the u1sync CLI tool [19:13] u1syncdaemon-agent [19:13] u1syncdaemon-tool [19:13] gnome-u1syncdaemon-applet then? [19:13] you are confusing even me [19:13] and i wrote this stuff :) [19:14] dobey: those follow the standard naming of similar processs (eg. run 'ps') [19:14] we can discuss renaming the processes themselves [19:15] but the documentation should reflect what they are actually called [19:15] things are a bit different for the server components, where the user doesn't see what they're actually called (and they don't even necessarily have real names themselves) [19:15] indeed. And I flook forward to reading documentation that isn't th result of reverse-engineering [19:16] the u1ftp/u1sycn pick was a bad one. I agree [19:16] sladen: no they don't [19:16] the processes are ubuntuone-syncdaemon and ubuntuone-client-applet [19:16] dobey: eh? Are you running KDE? [19:17] uh, no [19:17] "ubuntuone-client-applet" <--- another example of something that doesn't mention either filesharing/syncronisation in its name [19:17] in the case of ubuntuone-client-applet, it's possible that it may not be specific to filesharing [19:17] in the future [19:17] at least in principle [19:17] I think in practice it's probably going to eventually go away as a distinct entity [19:18] sladen: yes, because it's not specific to file sharing/storage [19:18] in fact, most of the work it does, is authentication [19:18] I can imagine that with a rewite, non of this stuff would be specific to fielsharing. [19:18] well the sync daemon is always going to be specific to filesharingstorage [19:19] the applet itself is mostly going away [19:20] anyway, to sum up [19:20] if the process is running on the user's machine and has a user-visible process name, we ought to use that process name in documentation referring to the process [19:20] whether or not the name is well-chosen [19:21] if it's a bad or confusing name, then we should discuss renaming the actual process [19:21] excllent [19:22] yes [19:28] (but in the meantime I think it's important that the documentation reflect what things are currently called) [19:29] it's a wiki. I won't revert it. I might even do it self. Although it's not as higher a priority as documenting other bits [19:29] s/self/myself/ [19:34] I won't twist your arm :) [19:38] thank you again for undertaking this [19:38] btw === yofel_ is now known as yofel [20:40] tcole: I've done u1ftp->u1sync [20:41] tcole: I think I'll leave the others for the mo [20:42] tcole: there is nothing "wrong" with the 'u1sync' name, whereas with the others (that I introducd the clash with), there "is" [20:43] (where "wrong" is of course, entirely my own humble opinion) [20:45] well, I would agree that they are suboptimial in some respects [20:46] suboptimial is a bettter word, yes [21:17] boas noites [22:31] Hola BUGabundo [22:31] ola facundobatista