Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting meeting, 2009-07-02 10:03:00

Minutes | Index | Today     Channels | Search | Join

All times shown according to UTC.

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 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

Minutes | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.