| Time | Nick | Message |
|---|---|---|
| 10:03 | bernie | present |
| 10:03 | bertf | waves |
| 10:03 | erikos | #TOPIC Journal - where are we now - where do we want to go! |
| 10:04 | #LINK http://wiki.sugarlabs.org/go/V[…]atastore/Proposal | |
| 10:04 | #LINK http://wiki.sugarlabs.org/go/Activities/Library | |
| 10:04 | sdziallas | waves |
| 10:04 | erikos | #LINK http://wiki.sugarlabs.org/go/D[…]m/Designs/Journal |
| 10:05 | garycmartin | waves |
| 10:05 | erikos | hi alsroot |
| 10:05 | alsroot | just want to mention that Library is all about object-centric view |
| 10:05 | erikos | welcome bernie |
| 10:05 | tomeu | hi! |
| 10:05 | alsroot | so, its only one part on new journbal |
| 10:05 | erikos | says hello to the wavers bertf sdziallas and garycmartin |
| 10:05 | tomeu, back from garden? | |
| 10:05 | tomeu | back |
| 10:05 | erikos | alsroot, yup - thanks for that addition |
| 10:06 | I want to quickly mention two little things at the beginning: | |
| 10:06 | eben | waves |
| 10:06 | erikos | a) development team lead |
| 10:06 | hi eben ;D | |
| 10:06 | b) feature process | |
| 10:07 | http://wiki.sugarlabs.org/go/D[…]ent_Team/Contacts | |
| 10:07 | I would suggest Tomeu as our lead for the development team | |
| 10:08 | as he has been around longest | |
| 10:08 | alsroot | +1 |
| 10:08 | garycmartin | +1 |
| 10:08 | erikos | and shown great skills |
| 10:08 | tomeu | I hope it won't be too much work |
| 10:08 | bertf | and manners |
| 10:08 | erikos | tomeu, nope - basically what you are doing already now |
| 10:08 | tomeu | ok, that's not too much :p |
| 10:08 | erikos | tomeu, of course we will help you ;p |
| 10:09 | alsroot | ..but multiplied bu 2 :) |
| 10:09 | tomeu | heh |
| 10:09 | erikos | :D |
| 10:09 | any objections? | |
| 10:09 | we could do voting as well or something | |
| 10:09 | but i think it is not really needed here | |
| 10:09 | counts | |
| 10:09 | 5 | |
| 10:09 | 4 | |
| 10:09 | 3 | |
| 10:10 | 2.5 | |
| 10:10 | 2 | |
| 10:10 | 0 | |
| 10:10 | hah! | |
| 10:10 | next topic :) | |
| 10:10 | b) Features for 0.86 | |
| 10:10 | I have sent a mail to the mailing list | |
| 10:10 | feedback about that welcome | |
| 10:10 | we can discuss further next meeting I guess | |
| 10:11 | just a note - to have a look | |
| 10:11 | so - journal - maybe we can start from the UI | |
| 10:11 | garycmartin | hasn't got through inbox yet today |
| 10:11 | erikos | garycmartin, that is fine ;p |
| 10:11 | what we want to achieve | |
| 10:11 | and then see how we get there | |
| 10:11 | eben, do you want to start | |
| 10:12 | eben, as you have been doing mockups already | |
| 10:12 | eben, and put a lot of thinking in it | |
| 10:12 | eben | Hmmm. |
| 10:13 | erikos | eben, maybe the difference between the action and object view |
| 10:13 | eben | There has been some good discussion so far in ML (I also replied to a few this morning, btw) |
| 10:13 | erikos | eben, right |
| 10:13 | tomeu | also garycmartin suggested some changes we cna target as a first step in 0.86 |
| 10:13 | eben | Should we go into detail about the action/object split? Or do we want to identify the low cost improvements to what exists now? |
| 10:13 | tomeu | then move forward after thsat |
| 10:14 | garycmartin | Is a stable action view really reachable in 0.86? |
| 10:14 | tomeu | not sure |
| 10:14 | eben | I can give a very brief summary of the idea behind action/object split, and then answer some questions, I suppose. |
| 10:14 | erikos | garycmartin, did you make suggestions in this thread? |
| 10:14 | eben | Sound good? |
| 10:14 | erikos | eben, sounds good with me |
| 10:14 | tomeu | though may exist the possibility of delivering a start of the action view in 0.86, and keep the current view as the main one |
| 10:15 | garycmartin | erikos, email thread yes. I have a mockup I almost got out last night but not enough time. |
| 10:15 | eben | OK. So, the impetus for the design here was the initial vision of the Journal as a log of everything a child has done. |
| 10:15 | erikos | garycmartin, ok ;p |
| 10:15 | eben | That vision was lost, in some sense, in the early iterations of the software because it was far easier to build a list of entries, which basically has a 1-1 correspondence with objects. |
| 10:16 | This had a couple of drawbacks. | |
| 10:16 | 1) Activities like Record were a "problem", since record creates a number of objects per activity "session" | |
| 10:17 | garycmartin | (tomey, actions could be recorded as non-resumable object entries in the current journal) |
| 10:17 | (tomey-> tomeu) | |
| 10:17 | eben | 2) We couldn't record interesting things in the Journal which related to more than one object, or to no objects at all (making friends, joining groups, etc.) |
| 10:17 | bemasc | garycmartin: this creates "journal pollution", making it very difficult to find the things a user actually cares about. |
| 10:18 | tomeu | I would also say that the current journal is the result of the tension between the intended journal and the file manager needed in some situations |
| 10:18 | garycmartin | bemasc: true |
| 10:18 | erikos | tomeu, yes - good point |
| 10:18 | tomeu | having two views instead of one relieves that tension, we can specialize each one without hurting the other |
| 10:19 | eben | So the basis of the idea is to show "actions" as "things that the child has done". Actions relate to any number of objects (often just one, in the case of many activities, eg. "Painted a picture of [my house]", but also many eg. "Recorded 12 photos of [butterflies]: [butterfly 1] [butterfly 2] ...") |
| 10:19 | erikos | eben, in case of the record example |
| 10:20 | eben, would the action view has an entry: recorded 12 pictures | |
| 10:20 | eben, and the objects themselves do live then in the object view | |
| 10:20 | eben | Each time an activity is worked on (or some other action occurs), it gets logged as a new action. Object view, on the other hand, represents each object ONCE (for all versions), and the object view looks very much like the currently Journal, which is basically a list of objects. |
| 10:21 | That's right. The record example would result in 1 new action, and 12 new objects. | |
| 10:21 | erikos | ok |
| 10:22 | eben | The action view shows actions as a summary, with the "resumable" item (if there is one) shown; actions can be expanded to reveal the thumbnails of all the related objects associated with the action. Those could then be opened individually, or their detail pages could be shown. |
| 10:22 | mk8 | where the tag associated with the datastore object is used? Only diruing the search? |
| 10:23 | eben | These mockups were created before we thought about exposing tags directly. But it's a good thing to bring up, because the basic idea here is that actions are immutable. |
| 10:23 | You can name/describe/tag objects, but not actions... | |
| 10:23 | tomeu | eben: what do you mean by resumable item? |
| 10:23 | alsroot | sorry, got disconneted from beginning |
| 10:23 | tomeu | I thought actions as a whole were resumable |
| 10:24 | will paste the log | |
| 10:24 | eben | Basically, any action that represents an activity session would be resumable, just as it is from the current Journal. |
| 10:24 | tomeu | bemasc, alsroot: http://pastebin.be/19510 |
| 10:24 | alsroot | tomeu: thanks |
| 10:25 | eben | In the record example, we'd have "Recorded 12 pictures of [butterflies]", and [butterflies] would be the title of the record session, along with the icon, resumable as usual. |
| 10:25 | tomeu | eben: and objects are only opened just like documents are in gnome? |
| 10:25 | eben: I thought the record session would be the action | |
| 10:25 | eben | tomeu: Some actions won't be. Eg. "You became friends with [tomeu]" is an action that can't be resumed. |
| 10:25 | tomeu | ok |
| 10:26 | eben | tomeu: Yes, if we don't support non-activity-session actions, then they are basically one and the same. |
| 10:26 | tomeu | ok, I think that's simpler and may work just as well |
| 10:26 | bemasc | Even some activities may not make sense to resume, if they are only producers of objects, and never consumers... but this is a detail for consideration after prototypes are in place. |
| 10:26 | erikos | eben, and let's say: I create a picture with record and resume it from the object view with Paint |
| 10:26 | eben | bemasc: good point. |
| 10:26 | bemasc | I think non-activity-session actions are valuable. |
| 10:27 | erikos | eben, then I get a new action item with the Paint activity |
| 10:27 | tomeu | yeah, I think the action-object split also helps with the issue that bemasc raises |
| 10:27 | what are non-activity-session actions? | |
| 10:27 | bemasc | erikos: yes. |
| 10:27 | eben | erikos: right, so if you choose to act on the OBJECT that was part of a previous record session, you get a new action eg. "Painted a picture of [butterfly 1]" |
| 10:28 | tomeu: things like "made a friend" We could also have "sent [object] to [person]", etc. | |
| 10:29 | bemasc | "backed up my data to [server]" is an interesting one. |
| 10:29 | tomeu | but what has that to do with the record action only containing media objects and not any session object? |
| 10:29 | eben | Back to erikos's example, this new action would refer to the same object as the record session, but it would point at a new version of that object. |
| 10:29 | alsroot | since we have short cycle for 0.86, maybe we should implement non-objects actions in next cycle? -- and use only objects related actions in 0.86? |
| 10:29 | erikos | eben, where versions come to play ;p |
| 10:30 | eben | tomeu: Ah right. This is where most of the fuzziness lived in the past. I think there would still be a "record session" object as well. |
| 10:31 | alsroot | thinks non-object actions could be painful to implement |
| 10:31 | bemasc | alsroot: it sounds trivial to me. |
| 10:31 | tomeu | ok, I don't know why is that needed, but maybe it's not worth debating that now |
| 10:31 | eben | Though, from a high level, this "session object" is really just another object referenced from the "action" container, and it happens to appear in the summary line. |
| 10:31 | bemasc | I don't see why a user-visible "session object" is useful. |
| 10:32 | eben | alsroot: Also, I specified non-activity....not necessarily non-object. We could consider having objects which represent people, with metadata about them, like an address book card in the details page, for instance. |
| 10:32 | bemasc | It also sounds extraordinarily difficult to implement, because it introduces the notion of inter-object dependencies, which is an enormous complication. |
| 10:33 | eben | bemasc: Because it is the thing which is named, and for which an activity icon exists, to resume the activity. |
| 10:33 | bemasc: I don't see how that's any different than what we have now. Right now there's just no action history to expose the relationships. | |
| 10:33 | bemasc | eben: why not just call it an "action" and keep it in the Actions view? |
| 10:34 | eben | That could be fine. |
| 10:35 | In this manner, a "Wrote a story about [sharks]" action would expand to show a single object: the document; but those would have the same name... | |
| 10:35 | alsroot | Q: will it(action related maint.) be fully user driven or it will be shell driven |
| 10:35 | eben | alsroot: 100% shell driven. It's an automatic log of things you do. (Though we've played with adding the ability to write your own Journal entries as well...) |
| 10:35 | bemasc | alsroot: rephrase, please. |
| 10:36 | oh | |
| 10:36 | eben | User interaction comes through naming objects, describing objects, tagging objects, etc. |
| 10:36 | alsroot | bemasc: in my mind implementing "clever" alogs in shell could be unpedictable for users -- so I'm strongly for user driven |
| 10:36 | s/alogs/algos | |
| 10:37 | bemasc | alsroot: who said anything about clever? |
| 10:37 | tomeu | I wold expect that most actions would be set by activities |
| 10:37 | plus some by the shell | |
| 10:37 | bemasc | I can't recall any algorithms mentioned thus far. |
| 10:37 | eben | Right. |
| 10:37 | tomeu | I'm not sure how we could give the user some change to alter it |
| 10:37 | maybe with the current title+tags+description dialog? | |
| 10:37 | bemasc | Things get hairy once you start talking about auto-pruning, but that hasn't been discussed (yet). |
| 10:37 | alsroot | well, I mean will user freedom to stop/continue/switch actions? |
| 10:38 | eben | For the most part, activities are given an "action" when they start up, they can add objects to that action while they run, and they can specify what the "phrase" for the action looks like, based on interaction, language, etc. |
| 10:38 | For them, there is almost no difference, apart from the capability of customizing the phrase. | |
| 10:39 | Record will still shove a bunch of objects into the DS...those will happen to be associated with the ongoing action. | |
| 10:39 | bemasc | (and the phrase is just a flourish, not a necessary component of the design) |
| 10:39 | eben | alsroot: If you stop an activity, you close up that action... |
| 10:39 | cjb | hi all |
| 10:39 | alsroot | eben: will Record choice to create its own activity(maybe user doesnt want to create new one) |
| 10:39 | ? | |
| 10:39 | eben | This is meant to be a mapping of the current interaction onto the Journal, not a new user managed system. |
| 10:40 | alsroot: it's own action, you mean? | |
| 10:40 | alsroot | eben: Records' own action |
| 10:40 | tomeu | may not be relevant now, but I guess actions are DS entries tagged as such which have no files, just metadata |
| 10:40 | alsroot | so user is not explicit creator |
| 10:40 | eben | If the user doesn't want to run Record, they won't run Record. :) If they do, then that action gets recorded in the Journal. |
| 10:41 | erikos | tomeu, yup - actions like 'frineds with x' ? |
| 10:41 | tomeu | erikos: all of them |
| 10:41 | eben | Now, it's up in the air right now whether actions which get "tossed" (objects not kept when stopped) still get logged as an action with no object... |
| 10:41 | alsroot | erikos: well, for me it looks like user driven ,then :) |
| 10:41 | erikos | tomeu, so you mean - we would need to alter the ds layout |
| 10:41 | alsroot | eben: ^^ |
| 10:41 | tomeu | erikos: no, just add a metadata property to distinguish between objects and actions |
| 10:41 | erikos | tomeu, or well - i guess just not record data |
| 10:41 | tomeu | yup |
| 10:42 | erikos | tomeu, ok |
| 10:42 | eben | alsroot: Sorry, what were you pointing me up at? |
| 10:42 | alsroot | eben: well, for me it looks like user driven ,then :) |
| 10:42 | eben | alsroot: Sure. Inasmuch as the user is making the actions that are being logged. :) |
| 10:42 | erikos | hi cjb - looks like the journal attracts attention ;) |
| 10:43 | bemasc | So... what was the purpose of this meeting? To discuss silbe's thing, I thought, but he's not here. |
| 10:43 | eben | The point is, the interaction isn't managed via some UI...a user doesn't click a button to make a "new action"....they just launch an activity. Or make a friend. etc. |
| 10:43 | erikos | bemasc, versions is only one point of the agenda |
| 10:44 | ok, looks like the action/object idea we have pretty much flashed out | |
| 10:44 | tomeu | bemasc: more about how to coordinate the different stuff that has happened lately around the journal: versions GSOC, library, diary and the journal |
| 10:44 | bemasc | ok |
| 10:45 | erikos | are there possibilities that we can make steps into that direction already for 0.86? |
| 10:45 | alsroot | erikos: but it was all about action-centric, isnt it? |
| 10:45 | bemasc | I ask because, additionally, "deep collaboration" turns out to be incompatible with our present versioning model. |
| 10:45 | eben | So, with all that said, I think there are 4 basic areas to discuss, somewhat (though not entirely) independetly: 1) should we create the action/object split 2) versions 3) improvements to the filters/tagging UI (which is used across both action & object views) and 4) Journal sharing |
| 10:46 | I think 3) is the most obvious place to start, because it has immediate impact. 2) is maybe next up, since it's basically required for action/object split, and a long missed feature. | |
| 10:46 | erikos | alsroot, it was about how both relate to each other - want to add something for the object view? |
| 10:46 | eben | 3) and 4) are kind of on their own as new features, and could come later. |
| 10:46 | tomeu | bemasc: present as in what is released? or what is proposed? |
| 10:47 | bemasc | tomeu: released... but it's not clear to me how it interacts with what is proposed (and without silbe I'm not sure what exactly is being proposed). |
| 10:47 | tomeu | bemasc: maybe you can put him quesitons on the ml based on his email and wiki page? |
| 10:48 | alsroot | erikos: my concern was to integrate Library code to Journal(its only about objects-centric) |
| 10:48 | eben | alsroot: I'm with you, as suggested above. I think refining the Journal toolbar (which I think can work for both action/object) might be the place to start refining. |
| 10:49 | erikos | eben, ok, does splitting views really requires versions? |
| 10:49 | eben, for a start one could copy the object as well, I guess | |
| 10:50 | eben, of course versions would be desired if possible | |
| 10:50 | eben, what I mean is: are versions a blocker for the split | |
| 10:50 | eben | erikos: I guess it doesn't necessarily require it, but it was designed with versions in mind. I think versions, and better filters/tagging, might be a bigger short term win, I guess. |
| 10:50 | But no, I suppose versions aren't necessarily a blocker. | |
| 10:50 | erikos | ok |
| 10:50 | alsroot | erikos: versions is just a tech details in case of object-centric |
| 10:51 | bemasc | Some new API is also going to be required, and maintaining backwards compatibility will be very interesting. |
| 10:51 | erikos | alsroot, yeah, this is what i thought |
| 10:51 | tomeu | bemasc: talking about versions only, right? |
| 10:51 | bemasc | tomeu: no, actions+objects. |
| 10:52 | silbe | uh, meeting already running? i thought it would start in 10 minutes... |
| 10:52 | cjb | silbe: timezone fail :) |
| 10:52 | erikos | silbe, oh - 14.00 UTC |
| 10:53 | eben | silbe: off by one error... |
| 10:53 | alsroot | bemasc: at least for OC(object centric) new code requires at least changes -- since it needs "collapsed" objects not versions |
| 10:53 | silbe | time was given in EST, i just fed it to date... |
| 10:53 | erikos | silbe, you are still in time for versions ;p |
| 10:53 | silbe | ok :) |
| 10:53 | erikos | silbe, the original mail was in UTC :/ anyhow - good that you are here |
| 10:54 | from what I heard so far: | |
| 10:55 | focusing on what eben said: better filter, toolbar - versions | |
| 10:55 | sounds good for 0.86 | |
| 10:55 | tomeu | (thunderstorm, might get offline again) |
| 10:55 | bemasc: why do you think actions needs new API? | |
| 10:56 | alsroot | eben: btw what do you think about sidebar(like in Library) to filter objects? |
| 10:56 | bemasc: http://wiki.sugarlabs.org/go/File:-1.png | |
| 10:57 | bemasc | tomeu: activities need some way to create an action, populate its description, and indicate its relationsihp to other datastore entries. |
| 10:57 | alsroot | bemasc: sorry, I mean eben |
| 10:57 | tomeu | bemasc: I think the DS API would suffice for that, but we could/should provide some high level API to make it easier |
| 10:57 | eben | alsroot: I responded on that point in ML. Honestly, I strongly prefer to avoid the sidebar to give the content all the space it needs. I think that we can collapse the current text-popup filters to icons with associated palettes instead, to get the richness you want without eating the space. |
| 10:58 | garycmartin | alsroot, (I'm not eben but will chip in) I struggle with that somewhat. Even though you can hide it, it seems complicated and eats lot's of space. |
| 10:58 | bemasc | tomeu: at a minimum, as you said, you will have to define new metadata properties. I would call this a "backwards compatible API change". |
| 10:58 | tomeu | bemasc: yup, agreed |
| 10:58 | eben | Basically, take something like that "person" palette in your sidebar, and replace the "who" popup filter with that, etc. |
| 10:59 | With popups instead of palettes, we can have grids, tag clouds, lists, even search fields and calendars or timelines, etc. | |
| 10:59 | We can do awesome stuff, but keep the UI down to the toolbar representing the "current filter", I think. | |
| 10:59 | erikos | alsroot, I think this is a nice example of what eben means: http://wiki.sugarlabs.org/go/D[…]Designs/Journal#2 |
| 11:00 | alsroot | eben: you mean *new* toolbars? |
| 11:00 | eben | bemasc, tomeu: on API, I think it *might* be possible to make it transparent to activities that don't update....we can have a default action like "worked on [activity title]"... |
| 11:00 | alsroot: No no. Even just the current Journal toolbar. New toolbars is yet another hot topic. ;) But let's not hit that one just now. | |
| 11:00 | tomeu | eben: yeah, we need base-lines most everywhere |
| 11:01 | eben | erikos: Actually, I don't have a good example. All of these mockups still use the text filters... |
| 11:01 | silbe | eben: how do you imagine that actions stuff to work, it terms of "low" level API usage? |
| 11:02 | eben | If we replace each of those big rounded gray things with a single icon representing the selected activity, or person, etc, with palettes instead of popup menus, I think we'd be in a great place to do neat things. |
| 11:02 | alsroot | eben: garycmartin: about toolbars instead of sidebar -- what about if I have tons of user tags(even maybe tree of them)? |
| 11:02 | eben | silbe: Basically, an action is defined by a single activity "session" (start to stop)....objects created by an activity over that period get associated with that action. |
| 11:02 | erikos | eben, i did not meant the toolbar - more the folding of an entry |
| 11:03 | tomeu | likes Eben idea |
| 11:03 | eben | alsroot: I think we can do smart things with the search box, and maybe have a little button next to it for revealing a tag list, or a tag cloud... |
| 11:03 | alsroot | eben: "little button next to it" to open what? |
| 11:03 | silbe | eben: so it's basically a collection identified by activity_id, like Record currently does? |
| 11:04 | eben | We could also have a button which used the tags to build a "soft hierarchy" browser, so you could click this button, and select "games > educational > memorize", even though those are just tags... |
| 11:04 | garycmartin | eben, I have a mockup 85% done, that sounds close (Journal toolbar with icons and grid palettes). |
| 11:04 | eben | alsroot: To open a palette of some kind with the list, or cloud, or menu, etc. |
| 11:04 | erikos | go garycmartin go! |
| 11:04 | tomeu | silbe: I like that possibility |
| 11:04 | silbe | i'm not sure it'll work like i expect the actions view to work... |
| 11:04 | eben | silbe: well.....by creator, not activity_id really. |
| 11:05 | silbe | eben: what's creator / how is it different from activity_id? |
| 11:05 | eben | The activity_id should be unique to a single activity....shouldn't be assigned to all objects created by an activity. |
| 11:05 | alsroot | garycmartin: did you shared your(non finished yet) mockup? |
| 11:06 | eben | Well, the activity_id is supposed to be the thing that says "if I resume this thing, what history does it belong to? Is a version of me already open? etc." |
| 11:06 | garycmartin | alsroot, one of the Journal buttons I have is for tags, I haven't worked on the palette content yet but it was going to be tag cloud like (tomeu was asking in ml). |
| 11:06 | eben | If I open a picture made by record, it's really just a new object, with no activity_id yet...I've never opened the picture. |
| 11:06 | bemasc | eben: one particularly tricky question for me is: can the type of an object change between versions? |
| 11:06 | silbe | eben: that's not the way Record currently works IIRC |
| 11:06 | eben | silbe: Some of my comments in the recent discussion with bemasc on versions/collaboration make this clear. |
| 11:06 | (well, clearer) | |
| 11:07 | bemasc | silbe: there is no system in place to allow it to work differently, currently. |
| 11:07 | eben | bemasc: I don't think so....I think if you wind up creating a new type, you get a new object, right? |
| 11:07 | silbe: Record is abusing activity_id...that was not its intended purpose. I didn't realize that's how it worked. | |
| 11:07 | silbe | eben: maybe we should start by giving clear definitions for activity_id, object_id and activity (?) |
| 11:08 | eben: ok, so it's even more of a mess than i assumed | |
| 11:08 | bemasc | eben: it's a tricky question. I open that photo from Record and edit it in Paint (or Gimp). Is it a new version of the same photo? Abstractly, I think so, but now it's a PNG, not a JPG. |
| 11:08 | eben | The purpose of the activity_id (I thought, anyway...maybe we need another id?) was to uniquely identify a "thread" of versions, especially across laptops in the collaborative space, but also locally. |
| 11:08 | tomeu | silbe: it's a very big mess |
| 11:09 | garycmartin | alsroot: mockups no, not shared yet. Might get them out by end of today. |
| 11:09 | eben | bemasc: Why wouldn't paint save it in the same format it opened it in? |
| 11:09 | bemasc | And you could say "well fine, but PNG and JPG are part of some class that you're allowed to move between"... but now if it's opened by Print and converted to PDF, or opened by Write and gets a caption added.... there's no clear boundary. |
| 11:10 | eben | bemasc: But yes, if that's the realty, then I guess we'd want that to just be a new version. Though it's probably bad practice to change the format of something without telling the user. (HIG note!) |
| 11:10 | silbe | eben: to be even more bold: let's define a whole new set of ids (i.e. with new names) so we don't depend on historical usage |
| 11:10 | tomeu | notes most users don't know about file formats |
| 11:10 | eben | bemasc: There's a difference between opening and importing, though. You don't open a picture in Write. You add a picture to a document. |
| 11:11 | Print is an oddball, I guess, but I suspect the proper behavior would be to keep a new document which represents the output... | |
| 11:11 | I think it comes down to specifying expected behaviors for activities. | |
| 11:11 | bemasc | eben: that's only true if Write won't open the picture directly (I don't know if it will). Consider Etoys, for example, which opens just about anything. |
| 11:11 | eben | They should respect the object they open. |
| 11:11 | silbe | eben: +2 on the printing. think of it as an export. we should keep track of exactly what left the system |
| 11:11 | bemasc | ok, so it's up to the activity whether it registers its work as a new version or a new object. That seems reasonable. |
| 11:12 | eben | bemasc: Yes, in my mind, that's actually awkward (etoys). But at least it behaves correctly, I think....it results in an etoys file. It doesn't overwrite that image I opened, right? |
| 11:12 | (Which makes it more like an import action, than an open action, even though it behaves that way) | |
| 11:12 | alsroot | garycmartin: but could you share your non-finished mockups -- i'm developing Library(hope it will be part of new journal) so I can start to implent it(at least basec ideas) |
| 11:12 | bertf | not anymore ... |
| 11:13 | erikos | alsroot is on fire ;D |
| 11:14 | ok, let's try to narrow down our brainstorming a bit | |
| 11:14 | eben | bertf: apologies if I made false assumptions or generalizations. :) Do you agree with my logic regarding "types" and general opening/closing behaviors? |
| 11:14 | tomeu | yeah, some focusing would be appropriate now |
| 11:14 | we aren't going to solve all issues today | |
| 11:15 | erikos | tomeu, yup |
| 11:15 | bertf | eben: no I meant it does not overwrite an image it opened anymore |
| 11:15 | erikos | garycmartin, and eben: can you guys try to mockup the filtering and tags? |
| 11:16 | I guess those additions can be made in any case | |
| 11:16 | bertf | eben: it imports it to a new document, to use your language |
| 11:16 | erikos | have no blockers like versions or a split |
| 11:16 | do people agree this is the first thing we want to tackle for 0.86? | |
| 11:16 | eben | bertf: Ah, cool. But if it *did* overwrite it, it would have kept the same format right? I think that's the real key. If you create a new format, it should probably be a new object...tricky around the edges, though, like JPG -> PNG... |
| 11:17 | erikos: Yes, I can't wait to see what Gray's got. I can iterate with him on some ideas. | |
| 11:17 | cjb | erikos: I guess there's a question of what to be done with the datastore; I don't feel like our intention was to maintain the current codebase forever. |
| 11:17 | erikos | eben, that sounds great |
| 11:17 | silbe | we should specify how the versions stuff is supposed to work though, so i don't have to block :) |
| 11:17 | garycmartin | erikos, let me bounce the mockups I'm working on now off the ml (later today) and then tweak/rework from there. |
| 11:17 | cjb | (but it's okay if you meant specifically not talking about that for now) |
| 11:17 | bertf | eben: no it actually overwrote it with an etoys project. which nobody liked =) |
| 11:17 | erikos | garycmartin, yup |
| 11:17 | tomeu | cjb: do we have a taker for that? |
| 11:17 | cjb | tomeu: I don't know. |
| 11:18 | eben | bertf: Ah. Understandably, I think ;) He heh. |
| 11:18 | alsroot | wants to make one tech thing clear - is it fine if Library will be a test platform for OC(object centric) related stuff of new Journal |
| 11:18 | tomeu | cjb: I'm happy to talk about that, but it's quite a bit of work |
| 11:18 | erikos | cjb, what are your main pressures? versions? |
| 11:18 | tomeu | cjb: I asked recently for someone to check where th egnome folks are going and see if we can merge at some point |
| 11:18 | cjb | erikos: full-text search, etc |
| 11:18 | oh! yeah, I wanted to mention that too. they just released 0.1 of zeitgeist. | |
| 11:18 | bemasc | cjb: what codebase? we kind of have a new one, thanks to tomeu. |
| 11:19 | tomeu | cjb: but we have fulltext search |
| 11:19 | erikos | cjb, ahhh, i see |
| 11:19 | silbe | tomeu: what are you talking about? |
| 11:19 | tomeu | thought cjb meant moving to something upstream instead of our DS |
| 11:19 | silbe | (and cjb as well) |
| 11:19 | erikos | cjb, the good thing is - our next sugarcamp will be with the gnome people next door |
| 11:19 | walterbender | tomeu: I plan to raise the subject at GUADEC |
| 11:19 | erikos | cjb, (november) |
| 11:19 | tomeu | silbe: gnome wants a journal in 3.0 |
| 11:19 | cjb | cool |
| 11:19 | tomeu | walterbender: nice! |
| 11:19 | erikos | cjb, maybe we can work with them towards that goal |
| 11:20 | silbe | ok, but we'll get a shiny new one within the next few weeks anyway |
| 11:20 | erikos | if we start discussion early it might make it in 0.88 |
| 11:20 | bemasc | silbe: what are your questions? |
| 11:20 | silbe | bemasc: what i'm currently mostly blocked at is the different ids stuff with conflicting definitions and uses |
| 11:21 | erikos | cjb, tomeu now i am a bit confused :/ what was the issue with the current DS? |
| 11:21 | silbe | if i can get a clear explanation of how it's supposed to work, i can finish the design and start implementing |
| 11:22 | tomeu | silbe: the trick is that each new version is smaller than the preceding, so we can keep having a new one every release |
| 11:22 | cjb | erikos: sounds like I'm just behind the times. I remember cscott's journal2 work, and it looked like a good plan for tagging, search, etc. |
| 11:22 | silbe | tomeu: ? |
| 11:22 | tomeu | erikos: well, we would like it to be upstream and that other desktops can read our data, etc |
| 11:23 | eben | silbe: Be sure to review the thread called "Sugar Presence Service and Resume Behavior" for some insight there. |
| 11:23 | tomeu | cjb: alsroot is working on some of those ideas with the aim of integrating them into sugar |
| 11:23 | erikos | cjb, ok, but the datastore provides the functionality for that I guess |
| 11:23 | tomeu | silbe: we should keep the DS codebase small while we don't know its future |
| 11:23 | eben | silbe: I'd like to hear a) how current behavior differs from the id definitions there and b) reasons for which those definitions are bad, or don't suffice, if they're not good enough. |
| 11:24 | erikos | tomeu, of course - the more of the parts that are upstream the better |
| 11:24 | tomeu | erikos: not for everything scott wanted, AFAIR |
| 11:24 | silbe | oh, BTW, eben, I'm a male :) |
| 11:24 | erikos | tomeu, ok |
| 11:25 | eben | silbe: Oh! My sincere apologies. :) I won't feel too guilty, though. with the name Eben I got copies of teen girl magazines in the mail all the time... |
| 11:25 | silbe | eben: one of the problems is that i didn't find an authoritative definition, just several bits and pieces |
| 11:25 | eben: no problem at all, just wanted to mention it | |
| 11:25 | eben | silbe: in practice, or in that discussion? |
| 11:25 | erikos | alsroot, about - the testing in Library part |
| 11:26 | silbe | eben: on the wiki and in the source |
| 11:26 | bemasc | silbe: I know about the activity_id and object_id. Are there others? |
| 11:26 | erikos | alsroot, sounds good - as it is a separate activity there should not be any issues, right? |
| 11:26 | eben | silbe: I feel that I have a pretty clear idea in my head of what we need, but I have no idea what's implemented now, and I'm sure that the more technically minded will be better to judge if what I think is reasonable is, in fact, reasonable. |
| 11:26 | silbe | bemasc: i've seen at least "activity" and "bundle_id" |
| 11:27 | eben: well, how about doing a good dump of your idea? than i can compare it to the current state of things. | |
| 11:27 | bemasc | bundle_id seems to be just the activity's dbus identifier, like "org.laptop.Record". |
| 11:27 | eben | silbe: bundle_id uniquely identifies an activity bundle...the activity_id (I think) should identify a unique instance (and it's history...each version would have the same acitivty_id) of that activity. |
| 11:27 | alsroot | erikos: I thought about using two packages from Library code base: one regular activity(there some points for that) and sucrose packages(which follow release cycle) |
| 11:28 | silbe | eben: knowing how it's *supposed* to work is exactly what i need right now |
| 11:28 | eben: what about several objects created by the same activity, like Record does? how are they related? | |
| 11:28 | erikos | alsroot, you mean for having it officaly as a sucrose package? |
| 11:28 | eben | silbe: I think the thread I referenced before is the place to discuss it. Most (all, I think, actually) of the definition is there, with some background and reasoning...if there are holes, that's the place to identify them. |
| 11:29 | erikos | alsroot, is this a matter of packaging? |
| 11:29 | alsroot, or any other reason for that | |
| 11:29 | alsroot | erikos: btw we still dont have code for AC(action-centric) code so maybe using it as a start for Journal2 code base |
| 11:29 | eben | silbe: They were created by the same activity. They will be referenced from the same action (in the future). Record could add some bit of metadata...some key it decides on...to relate them if it wants. |
| 11:30 | But those other objects are not a the instance of the Record activity that should be tracked by that activity_id. | |
| 11:30 | silbe | eben: and how would that action be represented in the metadata? |
| 11:30 | eben | They aren't versions of the record session. |
| 11:30 | of the record instance, or the photos? | |
| 11:30 | alsroot | tomeu: ^^^^ |
| 11:30 | tomeu: ^ | |
| 11:30 | tomeu: ^ | |
| 11:30 | silbe | ok, so activity_id is what tomeu and i called super_object_id |
| 11:30 | alsroot | counts lines |
| 11:31 | eben | As mentioned, Record could add its own key:value pair if it wants; the DS could also keep a list both of objects for each action, and actions for each object, as well, if we want. |
| 11:31 | tomeu | got disconnected again |
| 11:31 | eben | silbe: heh. Better to call it instance_id, or session_id, or history_id, or thread_id, perhaps? |
| 11:31 | bemasc | silbe: activity_id is supposed to represent a "session stream": all the objects associated with an activity session and any sessions resumed from that session etc. |
| 11:31 | tomeu | reads |
| 11:32 | silbe | eben: i wouldn't consider separate photos to be versions of the same object - they're different, just related by the context they were created in |
| 11:32 | erikos | tomeu, we have two threads at the moment: versions and Library |
| 11:32 | eben | bemasc: I agree with session stream, but disagree that it should be "all related objects".... |
| 11:32 | tomeu | alsroot: what's the question? |
| 11:32 | alsroot | tomeu: full log http://pastebin.be/19511 |
| 11:32 | :) | |
| 11:32 | eben | I think it should be all sessions....but not the other objects that are a byproduct of those sessions (eg. a photo taken in record) |
| 11:32 | tomeu | I actually have the log ;) |
| 11:32 | erikos | maybe we should do one after the other - a bit hard to follow ;p |
| 11:32 | bemasc | eben: I mean in the current system. I regard all these identifiers as problematic. |
| 11:33 | eben | bemasc: Oh, yes. Careful now. We're talking "should" here! :-P |
| 11:33 | silbe | bemasc: that's why i want clear, new definitions now |
| 11:33 | alsroot | tomeu: erikos: btw we still dont have code for AC(action-centric) code so maybe using it as a start for Journal2 code base |
| 11:33 | tomeu | alsroot: you mean a new code base? |
| 11:33 | alsroot | s/it/Library/ |
| 11:33 | tomeu: yup | |
| 11:33 | silbe | let's specify how it should work in future and only from that go to implementation and backwards compatibility |
| 11:34 | tomeu | alsroot: why that instead of working on a journal branch? |
| 11:34 | alsroot | tomeu: from scratch |
| 11:35 | cjb | alsroot: have you seen cscott's journal2 source, btw? it might be good for ideas. |
| 11:35 | erikos | tomeu, an activity is easier to deploy i guess - but if it is intended to go into the journal later anyhow, i would do a branch |
| 11:35 | alsroot, ^^^ | |
| 11:35 | eben | alsroot: Right. So "session stream" is pretty much the idea. Another way to think of it is the unique ID for the version history tree for any given object...all versions in that tree should share this ID. |
| 11:35 | alsroot | tomeu: erikos: my concern is -- I'm working on Library code now and its a good idea to work on new journal in one place instead of hacking Journal and Library |
| 11:35 | eben | So each version is uniquely identified by its (activity_id, version_id) pair... |
| 11:36 | tomeu | alsroot: yuo, I just want to know if you think my code is too horrible to work on top of it ;) |
| 11:36 | eben | but by looking at the activity_id, we'll know what objects (version of objects, really) are part of the same history. |
| 11:36 | silbe | tomeu: the current code is coupled tightly to the specific on-disk format. it's probably easier to do it from scratch instead of morphing it into something new that uses a VCS backend... |
| 11:36 | alsroot | cjb: I did, some texts.. but guess.. I should downlaod video |
| 11:36 | cjb | alsroot: anyway, it's http://dev.laptop.org/git/users/cscott/journal2 -- some of the ideas like exporting entries over RSS so they can be collated in the friends view seem pretty good. |
| 11:37 | yeah, there are screencasts too | |
| 11:37 | erikos | alsroot, with the new journal, will the Library be obsoleted? or does it offer some extra functionality? |
| 11:37 | cjb | (they're in docs/ in that tree) |
| 11:37 | silbe | ah, you're talking about the UI side - sorry, mistook for DS |
| 11:38 | alsroot | erikos: one point to have external activity is -- library object is like a collection of objects, user can share this colleciton(not all local objects) |
| 11:38 | erikos: and having this features for 0.82/0.84 as well | |
| 11:38 | bemasc | eben: I think we should do this not on IRC. Also, I think "activity_id" is a dangerous metaphor once we have multiple (object, version)s associated with a single activity checkpoint. |
| 11:38 | tomeu | silbe: you mean the DS, right? I was asking about the journal |
| 11:39 | oh, just read your clarification | |
| 11:39 | erikos | alsroot, hmm, making the functionality as well available in 0.82 |
| 11:39 | tomeu | I guess if both silbe and alsroot want to write the journal and DS from scratch, my code must suck |
| 11:39 | alsroot | erikos: yup, OC(object centric) |
| 11:40 | erikos: so users with 0.82/4/6 will share objects from each other | |
| 11:40 | silbe | eben: ok, so how do we tag a) documents created by a given activity and b) created as part of a session (stream?), i.e. identifying actions (BTW should it be a new action on activity stop / resume?) |
| 11:40 | tomeu | alsroot, erikos: one of the problems of having core functionality be activities that can be easily installed is that it's harder to document and support |
| 11:40 | erikos | tomeu, no time for tears ;p |
| 11:41 | tomeu, yeah - I wonder if we *really* need to backport | |
| 11:41 | silbe | tomeu: no offense intended at all - it's good for what it currently does, but not for what i intend it to do |
| 11:41 | eben | silbe: yes to new action on stop/resume. that's the basic idea. |
| 11:42 | silbe | eben: ok, so action = session, activity_id = session stream? |
| 11:42 | eben | silbe: I agree with bemasc: we should discuss details of these ids in ML... |
| 11:42 | alsroot | erikos: well Library doesnt do ilegal job, jsut ds api |
| 11:42 | silbe | (using activity_id for now until we find a better name) |
| 11:42 | bemasc | eben: ah, but is the action really "new", or is it internally represented as a new version of the invisible object that represents this thread? |
| 11:42 | alsroot | erikos: ..in most casess |
| 11:42 | eben | silbe: as I see it, yes |
| 11:42 | erikos | alsroot, I just mean in terms of extra work |
| 11:42 | alsroot, most cases --- aha! | |
| 11:42 | eben | bemasc: there would be a new version of the object created; a new action is added for the creation of the new version... |
| 11:43 | bemasc | eben: I am arguing that we can reuse our versioning both to trace object version and to trace action threads. |
| 11:43 | eben | Basically, there is an action per version. |
| 11:43 | erikos | alsroot, ok - can we describe the goal as: |
| 11:43 | alsroot | erikos: I think we(in Library) should support at least 0.84 |
| 11:43 | erikos | alsroot, library does object centric actions for 0.84 |
| 11:43 | silbe | eben: i agree half-way. one of the reasons i haven't dug too deeply into that thread yet is that a life chat is better (at least for me) to understand the basics. for definitions the mailing list is better, i agree. (not sure if you'll understand what i mean) |
| 11:43 | eben | bemasc: Yes, they are closely tied, as I mentioned above by likening the activity_id to the identifier of a given version tree. |
| 11:44 | erikos | alsroot, in newer releases the functionality will be available in the journal itself |
| 11:44 | alsroot | erikos: yup |
| 11:44 | eben | silbe: live chat is fine too; maybe we should schedule a separate discussion of that topic alone, sometime soon? |
| 11:44 | bemasc | eben: right, but it's not a version tree of an object, because the object could have been edited by different activities over its history. |
| 11:44 | or rather, it's not the version tree of any old object, but it could be the version tree of the hidden Action object. | |
| 11:44 | alsroot | erikos: at least, I think its the way to go |
| 11:45 | silbe | eben: i thought that's what this meeting is about :) |
| 11:45 | eben | bemasc: Right, which is why I suggested various terms other than activity_id as better... ;) |
| 11:45 | silbe: Well, alright then. If that's the case. I thought it was one of several topics. | |
| 11:45 | erikos | alsroot, ok, we made another step in defining/understanding the goals ;p |
| 11:45 | tomeu, what do you think? | |
| 11:45 | silbe | eben: it's just what i thought, no idea what was intended |
| 11:46 | eben | I also suggest this, though, because I'm technically at work...and have already devoted more attention than I should. :) |
| 11:46 | tomeu | erikos: can you summarize? |
| 11:47 | alsroot | all: stop talking, erikos is summarizing !!! |
| 11:47 | silbe | eben: i hope you can manage to spend some time on that topic nevertheless (whether sync or async) since it's quite important for my work |
| 11:47 | erikos | ok, I can summarize for two points (versions is still in discussion) |
| 11:48 | silbe | (not trying to put any pressure or something like that on you, though) |
| 11:48 | erikos | a) eben and gary will iterate over the tags/filters mockups |
| 11:48 | eben | silbe: yeah, definitely. Please ask any questions that arise in the ML thread there, and if needed we can schedule another IRC chat about it! |
| 11:48 | erikos | - we try to get this into 0.86 |
| 11:49 | b) for the object centric part we discussed aleksey will keep on working in Library | |
| 11:49 | - this can be used as is in 0.84 | |
| 11:49 | - and will be upstreamed in the Journal itself | |
| 11:49 | - might make it into 0.88 in the end | |
| 11:50 | - (the journal part) | |
| 11:50 | does that sound alright? | |
| 11:50 | alsroot | erikos: except that, I'll try to support 0.82 as well |
| 11:50 | erikos | alsroot, that is fine ;p |
| 11:51 | tomeu | erikos: can you summarize? |
| 11:51 | silbe | eben: sounds great, thx! |
| 11:51 | erikos | tomeu, what is unclear? |
| 11:51 | tomeu, or did you get disconnected? | |
| 11:51 | tomeu | erikos: what are you asking me? |
| 11:51 | erikos: got disconnected, but have the full logs | |
| 11:51 | (or so I think) | |
| 11:52 | erikos | <tomeu> erikos: can you summarize? <--- you said this |
| 11:52 | <erikos> a) eben and gary will iterate over the tags/filters mockups | |
| 11:52 | tomeu | erikos: and you asked me "what do you think?" |
| 11:52 | erikos | <erikos> - we try to get this into 0.86 |
| 11:52 | <erikos> b) for the object centric part we discussed aleksey will keep on working in Library | |
| 11:52 | <erikos> - this can be used as is in 0.84 | |
| 11:52 | <erikos> - and will be upstreamed in the Journal itself | |
| 11:52 | <erikos> - might make it into 0.88 in the end | |
| 11:52 | <erikos> - (the journal part) | |
| 11:52 | <erikos> does that sound alright? | |
| 11:52 | and you asked me again to summarize ;) | |
| 11:53 | tomeu | oh, so my irc proxy is not as good as I thought |
| 11:53 | sounds good, yeah | |
| 11:53 | erikos | ok - nooooow versions! |
| 11:53 | silbe | tadaaaaaa! |
| 11:53 | erikos | silbe, can you give us a quick summary |
| 11:53 | silbe, plans, status, where you need help? | |
| 11:54 | finds it a long meeting today | |
| 11:54 | silbe | erikos: well, i have a simple prototype that just adds version_id and uses (object_id, activity_id) in most places |
| 11:54 | erikos | we should meet more regularly so the meetings get shorter ;) |
| 11:54 | tomeu | design discussions always take a lot of time ;) |
| 11:54 | alsroot | erikos: np, we have enough time for 0.86 deadline |
| 11:55 | erikos | alsroot, I read that often from you ;p |
| 11:55 | silbe | based on the current data store code, so very basic, but the simple interface promised for GSoC is there |
| 11:56 | garycmartin | has gnawed both legs off trying to keep up with thread, but still alive. |
| 11:56 | silbe | for the "real thing" (i.e. with branch support and a VCS backend for storage) i need the activity_id vs. object_id vs, activity vs whatever mess sorted out |
| 11:56 | alsroot | garycmartin: :( -- i thought you are preparing mockups |
| 11:56 | tomeu | doesn't understand why we need nor branch support nor a vcs backend |
| 11:57 | erikos | silbe, so enlight us! why branch, why vcs? |
| 11:57 | silbe | tomeu: maybe we decide we don't want to use branch support long-term - but it's an option i'd like to give |
| 11:57 | erikos | silbe, tell us the design pat of things |
| 11:58 | s/pat/part | |
| 11:58 | tomeu | from what I understood about the user experience, we only need to know which entries are tip of a branch, and which are the ancestors of an entry |
| 11:58 | silbe | branches are meant to be created whenever the user resumes and edits a non-HEAD version |
| 11:58 | tomeu: that is basically branch support | |
| 11:58 | tomeu | for that, storing a version id of the form 3.2.4.1 would be enough |
| 11:59 | silbe: ok, sounded more work than adding a metadata property ;) | |
| 11:59 | cjb | if you use a vcs, you have to deal with merge conflicts |
| 11:59 | silbe | cjb: there won't be any merges |
| 11:59 | bemasc | cjb: we have no concept of merge. |
| 11:59 | is working on merge, but let's not make this meeting even longer. | |
| 12:00 | cjb | ok. so you want a database, and think that VCSs can behave as reasonable ones, I guess. |
| 12:00 | silbe | tomeu: well, it is, because i want to delegate storage to a ready, working and tested part of code, i.e. a VCS, instead of trying to build my own inside the data store |
| 12:01 | tomeu | silbe: sure, but there's also the risk of the vcs not doing exactly what you want, and thus running into even more trouble than the one you wanted to avoid |
| 12:01 | bemasc | silbe: I think writing our own VCS will be easier than interfacing to anyone else's (but we don't need to decide that now). |
| 12:01 | silbe | cjb: can you elaborate on the database stuff? |
| 12:01 | tomeu | (what happened to the first DS) |
| 12:01 | the last released DS uses two databases: filesystem and xapian | |
| 12:01 | do we need a third one? | |
| 12:01 | silbe | bemasc: the interface to git actually is pretty simple |
| 12:02 | cjb | silbe: well, just that a VCS stores blobs and knows how to merge them, and it sounds like you only want to store blobs, so maybe you're actually talking about a database. |
| 12:02 | tomeu | and ben's versions prototype used hg, which meant using a lot of code for almost nothing |
| 12:03 | silbe | cjb: i want to store blobs that are related to each other, i.e. are part of an anchestry graph and can be often be stored efficiently by using delta compression |
| 12:03 | tomeu | cjb: databases are not more about storing structured info than blobs? |
| 12:04 | cjb | silbe: that's a good point |
| 12:04 | bemasc | silbe: yes, but it doesn't do exactly what you want: (1) differential compression is a separate "pack" step, (2) git's diff algorithms are not pluggable and not appropriate for us, (3) much of it is written in Perl, etc. |
| 12:05 | tomeu | feels guilty for helping deviate erikos' meeting |
| 12:05 | silbe | bemasc: pack (or rather gc) gets called for each (write) action in my backend |
| 12:05 | erikos | tomeu, i guess the DS is not an easy subject |
| 12:05 | bemasc | anyway, as long as its a hard interface, we can write our own backend or write wrappers for others; we don't have to decide now. |
| 12:05 | tomeu | erikos: it's too much fun :p |
| 12:06 | erikos | tomeu, i wonder how we move best forward |
| 12:06 | silbe | bemasc: is there any part of the basic interface (commit, checkout etc.) still implemented in perl? |
| 12:06 | erikos | silbe, you mentioned a basic idea - easy to implement |
| 12:06 | bemasc | silbe: I'm not sure. |
| 12:06 | tomeu | erikos: we need to discuss silbe's API changes, then check out the implementation |
| 12:06 | erikos | silbe, is that an enhancement to the current DS? |
| 12:06 | silbe | bemasc: that's my intention with the VCS backends and getting away from depending on a specific on-disk structure |
| 12:07 | erikos: what do you mean exactly? | |
| 12:07 | erikos | <silbe> erikos: well, i have a simple prototype that just adds version_id and uses (object_id, activity_id) in most places |
| 12:07 | <silbe> based on the current data store code, so very basic, but the simple interface promised for GSoC is there | |
| 12:08 | is that meant to go into the current DS for 0.86? | |
| 12:08 | silbe | erikos: no, i don't think so (unless you decide otherwise) |
| 12:09 | it depends on what you want | |
| 12:09 | i.e. what features you expect of the data store and what the ratio of reuse-existing vs. implement-own should be | |
| 12:10 | erikos | well, and the timeline for those changes |
| 12:10 | have we defined the requirements somewhere? | |
| 12:11 | silbe | my current intention is to rely on sqlite (for metadata storage), git (for data storage) and later xapian (for probabilistic queries), using just some glue code to combine them |
| 12:11 | tomeu | silbe: please don't forget reliability and performance |
| 12:11 | alsroot | erikos: just very short list of them http://wiki.sugarlabs.org/go/D[…]d_benefit_Library |
| 12:11 | tomeu | silbe: I would like to avoid the errors of the previous implementations, not falling again on them |
| 12:13 | erikos | alsroot, but this is not about versions, right? |
| 12:14 | silbe | tomeu: my own code is designed for reliability (if you find any case i haven't catered for, please mention it). i have to rely (no pun intended) on the third party code to be working as expected (and defined in the document), of course - but given that those are all mature products i don't think that should be an issue. |
| 12:14 | alsroot | erikos: first feature about versions |
| 12:14 | tomeu | silbe: the older DS was rendered unusable in case of power loss, which is quite common with kids |
| 12:14 | erikos | alsroot, ok, i see |
| 12:15 | silbe | for git i've asked on the list and got the answer that it should be very resilient to crashes. mtd pointed out possible issues with large objects, though (kept entirely in memory) |
| 12:15 | (not reliability issues but performance / resource usage ones) | |
| 12:15 | tomeu | silbe: and the new one doesn't use a db because couldn't find one: fast, space efficient and robust enough |
| 12:15 | silbe | tomeu: have you taken a look at my design yet? |
| 12:15 | tomeu | silbe: not yet, but you mentioned sqlite for metadata storage |
| 12:15 | silbe | tomeu: interesting. what was the reason you ruled out sqlite? |
| 12:16 | tomeu | silbe: couldn't assure it met those qualities with enough margin to push it to XOs |
| 12:17 | silbe: with the current design, I'm able to stand behind its robustness | |
| 12:17 | so not a matter of principles, but based on the available resources | |
| 12:17 | many design decisions of the old DS were good if we could have had enough resources, but we hadn't those | |
| 12:18 | and power loss was common | |
| 12:18 | s/power/data | |
| 12:18 | silbe | tomeu: i.e. you didn't have time to verify it's good enough? no known issues? |
| 12:19 | tomeu | silbe: with the current design, I can assure a minimum of robustness |
| 12:19 | silbe: if we used xapian or sqlite to store the metadata, I wouldn't be able to do that | |
| 12:20 | silbe | tomeu: well, sqlite should be able to do that ;) |
| 12:20 | tomeu | silbe: how so? you can assure that sqlite will be up to the task? |
| 12:21 | silbe | tomeu: according to http://sqlite.org/testing.html they seem to use a pretty thorough test suite |
| 12:21 | tomeu | silbe: they have thousands of kids using it to store their work on olpcs? |
| 12:21 | silbe | especially testing things like behaviour in OOM and IO error conditions |
| 12:21 | tomeu | the earlier DS was very robust on the author's tests |
| 12:21 | it wasn't until people started using it that failed | |
| 12:22 | silbe | tomeu: http://sqlite.org/mostdeployed.html |
| 12:22 | bemasc | silbe: the real question is: what does sqlite buy you? |
| 12:22 | silbe | tomeu: i obviously can't give any guarantee, but it seems like quite a good fit |
| 12:22 | tomeu | silbe: you are saying that should be enough to convince me for people to ship that instead? |
| 12:23 | silbe: the problem is that we already shipped what seemed like a quite good fit and failed big time | |
| 12:23 | I don't think we should fail again that area | |
| 12:23 | another issue with the first DS is that the author didn't tested it in the XO | |
| 12:23 | so it was very slow, took a lot of disk space and memory | |
| 12:23 | we shouldn't regress there | |
| 12:25 | silbe | tomeu: fully understood - and i do have an XO for testing |
| 12:25 | tomeu | silbe: I know, but we shouldn't design, implement, then test on the XO and realize the desing doesn't scale |
| 12:26 | the author of the first DS also had an XO, just thought he was smart enough to not need to validate things first on the real hw | |
| 12:26 | silbe | tomeu: well, the basic design should be able to scale - and the specific backends can be exchanged |
| 12:26 | tomeu | and also subestimated the amount of things that can go wrong in the field (though granted he was doing the first implementation) |
| 12:27 | silbe | tomeu: one of the reasons for a more abstract design is that it can scale for different types of machines - there's no perfect tradeoff that fits all devices |
| 12:28 | tomeu | silbe: that's fine, I just would like that all future versions of the DS are based on the feedback we have to date and don't regress on serious stuff like robustness |
| 12:28 | silbe: well, but the current implementations has already well abstracted the components you mentioned before | |
| 12:28 | alsroot | tomeu: silbe: maybe the way to go is providing plugins/backends -- so deployer can decide which of them is useful for particular hw(old DS, new with versions..) |
| 12:28 | tomeu | actually, during development the backends changed until the best one was found |
| 12:28 | silbe | tomeu: of course. and robustness is priority number 0 for me - an unreliable data store is no data store but a junk yard. |
| 12:29 | alsroot: that's exactly what's intended - sorry if that wasn't clear enough | |
| 12:29 | tomeu | but isn't that what we have today? |
| 12:29 | alsroot | silbe: ahh.. ok, cool then |
| 12:29 | silbe | the first version is based on the components given above |
| 12:29 | tomeu: no, it's not | |
| 12:29 | tomeu: as i said, large parts are tied to your on-disk format | |
| 12:30 | tomeu | silbe: are you sure? |
| 12:30 | silbe | tomeu: perfectly, i've added version support to it |
| 12:30 | tomeu: i.e. i needed to change on-disk format | |
| 12:30 | tomeu | silbe: ok, but I wrote it |
| 12:30 | silbe: what do you mean by on-disk format? | |
| 12:30 | silbe | only the index stuff is separate |
| 12:30 | tomeu | we have three aspects to it: metadata, file and layout |
| 12:30 | each one has it's own component | |
| 12:31 | silbe | tomeu: the way data and metadata is stored on disk |
| 12:31 | tomeu | silbe: looks like you have modified some other code |
| 12:31 | silbe: each of those three aspects live in its own class | |
| 12:31 | metadatastore.py, filestore.py, layoutmanager.py | |
| 12:31 | silbe | tomeu: ok, to be more specific i needed to change layout and for that i needed to change lots of places in different files |
| 12:32 | let me do a quick diff for recall | |
| 12:32 | tomeu | silbe: well, layoutmanager is for that, if you really wasn't able to just modify that one (I don't see why), then we should have fixed that |
| 12:33 | I don't see why we couldn't use sqlite instead by just modifying metadatastore.py, or using git by just modifying filestore.py | |
| 12:34 | during development I tested different implementations for each component, so I'm pretty sure of that | |
| 12:35 | erikos | ok, at least I have to get a bit of fresh air now |
| 12:36 | I think we need another iteration of the datastore - shall we do another meeting for that? | |
| 12:36 | tomeu | erikos: are we done then? |
| 12:36 | I need to read silbe's email and wiki notes next | |
| 12:36 | erikos | tomeu, yup - i have to get into it as well |
| 12:36 | we can either do DS/versions again next week thursday | |
| 12:37 | or if sascha feels blocked - early next week | |
| 12:37 | what do others think? | |
| 12:37 | silbe | filestore.py, layoutmanager.py, migration.py (obvious), optimizer.py needed path changes |
| 12:38 | tomeu | silbe: nothing that couldn't be fixed by pushing more stuff into layoutmanager.py? |
| 12:38 | erikos: I'm not sure without reading what he wrote to date | |
| 12:38 | silbe | tomeu: might be fixable, yes. |
| 12:39 | erikos | tomeu, you mean - when to meet? |
| 12:39 | silbe | well, the current prototype is effectively done, but very basic |
| 12:39 | tomeu | erikos: yeah, or what to discuss when we meet |
| 12:39 | lucian__ | sorry if i'm offtopic, couldn't kde's nepomuk serve as the datastore? |
| 12:39 | (the backend) | |
| 12:39 | silbe | for the next one i'm in design phase and somewhat blocked |
| 12:40 | tomeu | lucian__: there's several projects I would like to look into if I had the time |
| 12:40 | silbe | lucian__: url? |
| 12:40 | lucian__ | silbe: http://nepomuk.kde.org/ |
| 12:40 | tomeu | or to lobby so they extend their scope if necessary |
| 12:40 | silbe | tomeu: can you send me a list? |
| 12:40 | lucian__ | silbe: it's a semantic desktop store, has a nice dbus api |
| 12:40 | erikos | tomeu, silbe ok, my main point is - let's discuss things early |
| 12:41 | so nobody is running into a direction and then it is too late | |
| 12:41 | and I want to figure out what/if we do for 0.86 of course | |
| 12:41 | tomeu | silbe: nepomuk, tracker, zeitgeist, alexl's nautilus metadata stuff |
| 12:42 | silbe | erikos: sure. though i might decide to just start working on a new prototype (based on my proposal) after we entangled the id stuff. after all, i'm supposed to produce code for GSoC, not fill IRC logs and mailing list archives |
| 12:42 | we can still adjust later | |
| 12:42 | erikos | silbe, of course you can produce a mass of code |
| 12:43 | tomeu | erikos: gsoc students are not required to push their code to upstream, so makes sense for them to focus on their project during the summer |
| 12:43 | silbe | tomeu: is any of it in a usable state already? |
| 12:43 | erikos | silbe, if it gets integrated later is another topic |
| 12:43 | tomeu | silbe: what is it? |
| 12:43 | erikos | tomeu, that is fine with me |
| 12:43 | silbe | well, integration is an important goal for me - otherwise i would not do it |
| 12:44 | erikos | so I can take ds/versions just of the 0.86 roadmap, i guess |
| 12:44 | silbe | tomeu: the projects you listed |
| 12:44 | erikos: why? | |
| 12:44 | tomeu | silbe: don't think so, but I haven't had time to check |
| 12:44 | it's more of a longer term goal | |
| 12:44 | silbe | tomeu: ok, that was my impression last time i checked as well |
| 12:44 | tomeu | I was happy enough to make sure that 0.84 had a DS that wouldn't crash every few days |
| 12:45 | erikos | <silbe> erikos: sure. though i might decide to just start working on a new prototype (based on my proposal) after we entangled the id stuff. after all, i'm supposed to produce code for GSoC, not fill IRC logs and mailing list archives |
| 12:45 | silbe | i think the most important thing for 0.86 is to decide a) what we want (features, behaviour) and b) how we want it (API) |
| 12:45 | erikos | silbe, ^^^ |
| 12:46 | silbe | based on that, i can either tweak the current DS some more or do a new one |
| 12:46 | erikos | well, that is why i said let's discuss it |
| 12:46 | silbe | maybe even both, with the new one being targeted for 0.88 so we have more time for crash testing it |
| 12:47 | erikos: i was puzzled why you wanted to take it off the 0.86 roadmap - i don't see any reason for that (yet) | |
| 12:47 | erikos | silbe, I am a bit puzzled too |
| 12:47 | silbe | that i need to keep going for GSoC doesn't mean we'll not have a working, agreed on solution for 0.86 |
| 12:48 | erikos | right, and that for we need to discuss that |
| 12:48 | why I said let's do a meeting | |
| 12:48 | or make a ml thread | |
| 12:48 | silbe | it's just that i won't block on the design decisions for too long - if we decide to do something different than i implemented, i'll adjust it |
| 12:49 | erikos | http://wiki.sugarlabs.org/go/D[…]ease/Roadmap/0.86 |
| 12:49 | we do not have much time, and I rather nag people sooner then later ;p | |
| 12:49 | silbe | erikos: the part referenced on the roadmap is finished |
| 12:50 | (at least the non-optional stuff) | |
| 12:50 | erikos | and it is based on the current DS, right? |
| 12:50 | silbe | yep |
| 12:51 | small changes scattered all over the place, but nothing big | |
| 12:51 | the API (esp. Python side) can be tweaked to reduce the number of changes, but that's just another reason to discuss future API | |
| 12:51 | erikos | ok, it sounded like we need to rewrite everything from scratch earlier |
| 12:52 | so we should try to untangle: | |
| 12:52 | a) short term (0.86) | |
| 12:52 | b) longer plan | |
| 12:52 | silbe, http://wiki.sugarlabs.org/go/Features/Policy | |
| 12:52 | silbe, i posted that today | |
| 12:53 | silbe, I hope it helps to define the exact feature for the release better | |
| 12:53 | cjb | erikos: hm, I feel like we've always done (a), and never realized that if we keep iterating on this we won't get to (b). :) |
| 12:53 | silbe | erikos: the rewrite has two purposes: a) branch support (could be done otherwise as well) and b) modularisation so we can use different backends on different types of systems (disk/memory/cpu tradeoff) |
| 12:53 | cjb | it would be great to just "do it right", whatever that means |
| 12:54 | erikos | cjb, we failed as well in trying to do it right, several times |
| 12:54 | tomeu | cjb: I was thinking that when we tried to do b), nothing happened and we had to live with whatever we had |
| 12:55 | silbe | well, the point is that for a) we need to change API (if we want to include version support), so i'd like as much of b) as possible to go into the API changes, otherwise we'll break API next release again |
| 12:55 | cjb | tomeu: that happened too :) |
| 12:55 | but that just says that we're not accomplished enough at doing hard software design yet | |
| 12:55 | erikos | cjb, I try to start talking here about 0.88 already as well |
| 12:55 | cjb | I don't think it's a good reason to give up on it, though |
| 12:55 | erikos | cjb, so we can plan a bit ahead |
| 12:55 | cjb | erikos: yeah, if there's a plan where 0.86 and 0.88 go together well, that's good |
| 12:55 | silbe | oh, even listed as an example ;) |
| 12:55 | tomeu | cjb: well, talking to myself, I haven't accomplished much in doing good requriements analysis |
| 12:56 | s/to/for | |
| 12:56 | cjb | tomeu: :) |
| 12:56 | tomeu | so not knowing what the user needs, I would favor small incremental steps that allowed us to understand better what's required in th elong term |
| 12:56 | cjb | oh, heh, I thought you meant that you hadn't done good requirements analysis because you'd been talking to yourself :) |
| 12:56 | tomeu | but that's to be discussed case by case |
| 12:56 | heh :p | |
| 12:56 | that's also true | |
| 12:57 | silbe | what i'd like to do is to sort out the current mess of ids for 0.86 and cleaning up the API a bit as well (like in my document) |
| 12:57 | tomeu | that would be quite a lot already, from my POV |
| 12:57 | erikos | silbe, so yeah, it is good to have the long term plans in mind when making incremental changes (to your API note) |
| 12:57 | silbe | and for 0.88 we could add (=> no changes, just enhancements) probabilistic query support (xapian) |
| 12:59 | tomeu | silbe: have you already thought about language processing issues in xapian? |
| 12:59 | that would score higher than probabilistic search | |
| 12:59 | silbe | tomeu: i think it's mostly a case of defining the expected behaviour - the actual code changes are similar to the current one: scattered of large pieces of code, but only small ones each time |
| 12:59 | erikos | really needs fresh air now |
| 13:00 | tomeu | silbe: yeah |
| 13:00 | silbe | tomeu: i intend the 0.86 query API to do basic attribute search only, no interpretation and language stuff |
| 13:00 | tomeu: that's part of Information Retrieval for me | |
| 13:00 | tomeu | basic attr search is not what we have now? |
| 13:00 | and what's part of information retrieval for you? | |
| 13:01 | silbe | tomeu: it is what we use now |
| 13:01 | tomeu: in theory we support IR as well, using query={'query': 'Xapian query string'} | |
| 13:01 | but i haven't seen any code use it | |
| 13:01 | tomeu | silbe: that depends on what the user types in there |
| 13:02 | it is xapian that parses the query string | |
| 13:02 | silbe | and relevance sorting is invalidated by always doing timestamp sorting anyway |
| 13:02 | tomeu | but we are sorting by date, not by relevance |
| 13:02 | right | |
| 13:02 | silbe | tomeu: so journal passes it through from the search bar? |
| 13:02 | tomeu | yup |
| 13:02 | silbe | seems i haven't seen that part of the code yet |
| 13:02 | tomeu | so I'm not sure how we can expose probability ther |
| 13:02 | erikos | i will stop the meeting - is that fine (you can continue of course) |
| 13:02 | silbe | had no object_id in it ;) |
| 13:03 | tomeu | erikos: good with me |
| 13:03 | silbe | erikos: all right with me |
| 13:03 | let's move over to #sugar :) | |
| 13:03 | erikos | #endmeeting |
