[00:01] <nhaines> Is file storage the only planned feature in the karmic timeframe?
[00:03] <dobey> no
[00:04] <nhaines> Ooh.  Are other details available yet?
[00:05] <dobey> some things were discussed at UDS, yes
[00:06] <nhaines> Hrm.  I'll have to dig around, then.
[00:06] <dobey> the big thing being the 'structured storage' stuff (horribly confusing name that is)
[00:06] <nhaines> Structured storage?
[00:06] <dobey> i think there are some blueprints for it
[00:07] <dobey> syncing and storage of contacts for example, with the ability to replicate your contacts to other PCs on your LAN easily
[00:08] <greg-g> 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] <nhaines> greg-g: no, it doesn't.
[00:08] <greg-g> nhaines: thanks.
[00:08] <dobey> i think we ignore symlinks because doing The Right Thing (TM) with them is insanely difficult
[00:08] <nhaines> greg-g: no prob.  Best way is to do it the other way around: symlinks *into* ~Ubuntu One
[00:09] <nhaines> I remember hearing a bit about integrated contacts but I thught it was further off.
[00:09] <greg-g> 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] <dobey> we're trying to do as much as we can, as fast as we can
[00:10] <greg-g> dobey: makes sense
[00:10] <nhaines> dobey: frankly, I thought cloud file synchronization was pretty compelling by itself.
[00:10] <nhaines> On the other hand, I'm looking forward to other projected features such as screen sharing.
[00:11] <dobey> the most compelling feature is the desktop integration, really
[00:12] <dobey> although, i really wish i had the Pre SDK right now
[00:15] <nhaines> Does desktop integration refer to the client and the Nautilus extensions?
[00:16] <dobey> currently, that is what we have, yes
[00:17] <dobey> but moreso, it refers to things we'll hopefully be doing in the relatively near future :)
[00:20] <dobey> anyway, must go now... later
[00:24] <nhaines> dobey: later.  :)
[03:32] <VK7HSE> Thanks to all the developers for the update on the website for removing shares !!!  \o/
[03:33] <jblount> VK7HSE: :)
[03:35] <dobey> heh
[03:36] <VK7HSE> dobey: I just read the update from twitter !!!
[03:38] <dobey> ah
[03:38] <dobey> i blame jblount
[03:39] <jblount> dobey: I'm guessing you're right. I'm also sneaking people in the back door on twitter.
[03:39] <dobey> that's something you'll have to discuss with your wife, not me
[03:40] <jblount> dobey: ZOMGROFLMAO!@$!
[03:40] <VK7HSE> :-/  (lol)
[03:41] <dobey> heh
[03:59] <dobey> oi. must get some sleep
[08:30] <[Puck]> hi everyone
[10:27] <sladen> dobey: say "Your openID" and "View your subscriptions"
[10:28] <sladen> greg-g: swap the directory and the symlink around
[15:35] <sladen> 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] <sladen> __lucio__: yeah, stevea mentiond that too.
[15:39] <sladen> __lucio__: does storagefsd also talk to updown ?
[15:40] <__lucio__> sladen: no, they just share some code
[15:40] <sladen> 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] <sladen> __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] <sladen> and the instance of updown runs on the same macine as the instance of the ubuntuone-file-storage-api-server
[15:47] <sladen> 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] <sladen> 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] <sladen> is there a better name for "the unamed-serivce-at-www.ubuntuone.com/files"
[15:51] <Chipaca> no, updown runs on separate machines
[15:51] <Chipaca> from api, I mean
[15:53] <dobey> sladen: better name than?
[15:53] <sladen> 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] <dobey> sladen: it is the web ui for file storage service
[15:54] <sladen> web ui.  k.
[15:54] <Chipaca> sladen: webui :)
[16:01] <facundobatista> Hi all
[16:02] <__lucio__> facundobatista: hey! welcome back! youre late :P
[16:02] <facundobatista> __lucio__, indeed
[16:02] <__lucio__> facundobatista: when did you arrive? how was it?
[16:03] <facundobatista> __lucio__, a few hours ago... the plane landed with fog, too much fog
[16:20] <statik> hello world
[16:25] <facundobatista> Hi statik
[16:26] <dobey> hola
[17:37] <sladen> tcole: I clashed with you splitting  updown and webui.  Which of those does webstorage correspond to?
[17:40] <tcole> ah
[17:40] <tcole> webui
[17:40] <tcole> updown is barely a user-visible thing
[17:50] <sladen> tcole: what's the name of the server that 'updown' runs on?
[17:50] <sladen> eg. something-1.ubuntuone.com
[17:52] <sladen> 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] <tcole> that's actually a good question
[17:53]  * tcole checks
[17:53] <tcole> updown.ubuntuone.com
[17:59] <sladen> tcole: can yu check that  https://wiki.ubuntu.com/UbuntuOne?action=diff&rev2=17&rev1=15  is correct
[17:59] <statik> 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] <tcole> sladen: yes, that's just about right
[18:01] <sladen> statik: oh it's difference, we need both hands to spell the alphabet :)
[18:01] <tcole> sladen: updown is quite simple, it just checks access permissions in the database and basically does passthru to S3 as you describe
[18:02] <sladen> 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] <tcole> 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] <sladen> it introducs too many concepts  ("view" "share" "subtree") in the same sentence without giving them familiar equivalents
[18:04] <sladen> 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] <sladen> and read-only is basically one-way mirroring
[18:06] <tcole> that sounds good
[18:06] <tcole> while it isn't terribly important to most users, that fits well with the way u1sync works, too
[18:08] <sladen> that's simple commandline/vcs/ftp-like tool?
[18:08] <tcole> yes
[18:08] <__lucio__> mmh. not so much as ftp but maybe rsync.
[18:09] <tcole> it lives somewhere between bzr and rsync I think
[18:09] <__lucio__> yes
[18:10] <dobey> under a bridge. and it demands payment for passage when you approach it
[18:11] <tcole> no, that's u1troll
[18:11] <tcole> for our previously unannounced automated trolling service
[18:12] <tcole> it's a bit like Amazon's Mechanical Turk, only focused on serving the Internet trolling community
[18:13] <tcole> *crickets*
[18:13] <tcole> (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] <tcole> well, it's more about giving them an opportunity to monetize their trolling skills
[18:16] <sladen> 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] <tcole> hm, not precisely
[18:16] <sladen> 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] <tcole> no
[18:17] <tcole> new versions of a file are (at least in theory) the same object
[18:17] <sladen> pointing to a different blob?
[18:17] <tcole> yes
[18:17] <sladen> okay.  So how do you find out what to re-mirror
[18:17] <tcole> 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] <tcole> I forget offhand whether we filter such rename + creates out at the moment or not
[18:18] <tcole> sladen: from the POV of clients talking the storage protocol, they get push notifications when particular nodes change
[18:18] <sladen> is any history kept, or is it the blob reference just overwritten straight
[18:18] <tcole> lucio: does syncdaemon transfer file identity on rename+replace yet?
[18:19] <tcole> right now it's overwritten, though that will change
[18:19] <tcole> well, it'll still be overwritten
[18:19] <tcole> but there will be a log alongside
[18:19] <tcole> maintaining history
[18:19] <sladen> tcole: so if I connect and in between, 20 objects were updates, the client gets 20 notifcations delivered at once?
[18:19] <tcole> sladen: when you connect, the client is responsible for spidering the tree and identifying changes on its own
[18:20] <tcole> sladen: since the server doesn't (can't, really..) keep track of "what you missed since you last connected"
[18:20] <tcole> 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] <tcole> the push notifications are just for changes since the client connected
[18:21] <sladen> Ah, so the unsolicated push notifications are merely a convenience feature.  They aren't actually essential to the operation
[18:21] <sladen> convience/optimisation
[18:22] <tcole> more or less
[18:22] <tcole> clients could poll but that would be pretty slow
[18:22] <tcole> u1sync doesn't bother with the push notifications since it's more of a one-shot deal
[18:23] <tcole> rather than something which stays connected persistently
[18:23] <tcole> __lucio__: ping
[18:24] <__lucio__> tcole: here
[18:25] <tcole> __lucio__: did we ever do that thing in syncdaemon with recognizing text editor moves/renames when updating files?
[18:25] <tcole> 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] <tcole> 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] <tcole> yes
[18:57] <sladen> tcole: what about 'u1r'  it sort of rhymes with 'bee-zed-arr'
[18:57] <tcole> for what?
[18:58] <sladen> tcole: the commandline one-shot tool that you are likely to need to type repetively
[18:58] <tcole> u1sync seems fine to me
[18:58] <sladen> the name 'u1ftp' I've given it at the moment is not quite right
[18:59] <tcole> definitely not
[18:59] <tcole> well, from my point of view
[18:59] <sladen> and u1sync is confusing as it is separate from/incompatible with the the rest of the u1sync infrastructure
[18:59] <tcole> u1sync is the one component with a specific, short name
[19:00] <sladen> https://wiki.ubuntu.com/UbuntuOne#General%20concepts
[19:01] <tcole> I'm not renaming the program :P
[19:02] <sladen> yeah...
[19:02] <sladen> I think for clarity, I'll rename it in the doc though
[19:03] <tcole> I'm not sure that will bring clarity
[19:03] <tcole> people will be looking for a u1ftp command or whatever
[19:03] <sladen> how does having the same name as something unrelated help?
[19:03] <tcole> it didn't until you gave something else a colliding name
[19:04] <tcole> I appreciate what you're doing
[19:04] <tcole> 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] <tcole> er, FAQ
[19:06] <sladen> Duely noted
[19:06] <dobey> yeah, i don't understand why you want to rename things in the FAQ
[19:06] <dobey> it's not really a fitting thing for documentation to do
[19:07] <tcole> I think it would be best, if you're giving things alternate names
[19:07] <tcole> to make it clear that the names are alternate names by using spaces and titlecase
[19:07] <tcole> rather than making them look like program names
[19:07] <tcole> and then mentioning the actual program names in the relevant sections
[19:07] <tcole> rather than leaving it for a table at the end
[19:09] <sladen> 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] <tcole> I have less objection to renaming that
[19:10] <tcole> 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] <tcole> there's a big disconnect there between the documentation and the actual user view
[19:11] <tcole> and if you're calling it that because you've already called something else u1sync ... maybe you shouldn't be doing that
[19:11] <tcole> we do need to give users names to call things
[19:12] <tcole> but what we don't want to do is create an extra layer of indirection
[19:12] <tcole> between the documentation and the user-visible system
[19:12] <sladen> 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] <tcole> any of the code under canonical.ubuntuone.storage.u1sync is specific to the u1sync CLI tool
[19:13] <sladen> u1syncdaemon-agent
[19:13] <sladen> u1syncdaemon-tool
[19:13] <sladen> gnome-u1syncdaemon-applet then?
[19:13] <dobey> you are confusing even me
[19:13] <dobey> and i wrote this stuff :)
[19:14] <sladen> dobey: those follow the standard naming of similar processs (eg. run 'ps')
[19:14] <tcole> we can discuss renaming the processes themselves
[19:15] <tcole> but the documentation should reflect what they are actually called
[19:15] <tcole> 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] <sladen> indeed.  And I flook forward to reading documentation that isn't th result of reverse-engineering
[19:16] <sladen> the u1ftp/u1sycn pick was a bad one.  I agree
[19:16] <dobey> sladen: no they don't
[19:16] <dobey> the processes are ubuntuone-syncdaemon and ubuntuone-client-applet
[19:16] <sladen> dobey: eh?  Are you running KDE?
[19:17] <dobey> uh, no
[19:17] <sladen> "ubuntuone-client-applet" <--- another example of something that doesn't mention either filesharing/syncronisation in its name
[19:17] <tcole> in the case of ubuntuone-client-applet, it's possible that it may not be specific to filesharing
[19:17] <tcole> in the future
[19:17] <tcole> at least in principle
[19:17] <tcole> I think in practice it's probably going to eventually go away as a distinct entity
[19:18] <dobey> sladen: yes, because it's not specific to file sharing/storage
[19:18] <dobey> in fact, most of the work it does, is authentication
[19:18] <sladen> I can imagine that with a rewite, non of this stuff would be specific to fielsharing.
[19:18] <dobey> well the sync daemon is always going to be specific to filesharingstorage
[19:19] <dobey> the applet itself is mostly going away
[19:20] <tcole> anyway, to sum up
[19:20] <tcole> 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] <tcole> whether or not the name is well-chosen
[19:21] <tcole> if it's a bad or confusing name, then we should discuss renaming the actual process
[19:21] <sladen> excllent
[19:22] <dobey> yes
[19:28] <tcole> (but in the meantime I think it's important that the documentation reflect what things are currently called)
[19:29] <sladen> 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] <sladen> s/self/myself/
[19:34] <tcole> I won't twist your arm :)
[19:38] <tcole> thank you again for undertaking this
[19:38] <tcole> btw
[20:40] <sladen> tcole: I've done u1ftp->u1sync
[20:41] <sladen> tcole: I think I'll leave the others for the mo
[20:42] <sladen> tcole: there is nothing "wrong" with the 'u1sync' name, whereas with the others (that I introducd the clash with), there "is"
[20:43] <sladen> (where "wrong" is of course, entirely my own humble opinion)
[20:45] <tcole> well, I would agree that they are suboptimial in some respects
[20:46] <sladen> suboptimial is a bettter word, yes
[21:17] <BUGabundo> boas noites
[22:31] <facundobatista> Hola BUGabundo
[22:31] <BUGabundo> ola facundobatista