* Now talking on #olpc-meeting
* Topic for #olpc-meeting is: OLPC (http://laptop.org) meetings
* Topic for #olpc-meeting set by neuralis at Sat Dec 22 05:32:28 2007
<erikos> hello welcome to this week's sugar meeting
<erikos> who is around today?
<tomeu> me!
* mchua (n=mchua@cpe-66-108-80-238.nyc.res.rr.com) has joined #olpc-meeting
<garycmartin> me too.
* bemasc is here
<erikos> hi --- and eben is here too i guess
<erikos> http://wiki.laptop.org/go/Sugar_dev_meeting#Tuesday_April_08_2008_-_17.00_.28UTC.29
<erikos> as you might have seen eben sent out a todo list yesterday - which is today's topic
<tomeu> which are the controversial topics?
<erikos> eben was saying that the ps - parts where discussed yesterday
* |ypod| (n=ypod@1cc-dhcp-112.media.mit.edu) has joined #olpc-meeting
<erikos> personally i am not so sure about the overhead of the avatar images
<bemasc> erikos: each image would probably be much less than 10 KB
<eben> erikos: So, the overhead really depends on the implementation.
<bemasc> erikos: it may be too much overhead, but it is hard to predict
<eben> erikos: A hash could be passed around most of the time, and compared against a local cache for people we know
<garycmartin> avatar images: yea I'd vote they are a low priority, pretty, but non-essential.
<eben> erikos: and then only if the hash is different, or we find a person we've never seen, do we actually make the request for the image.
<erikos> eben: using hashes would reduce overhead indeed
<bemasc> eben: I think your list is basically not controversial.  All the ideas are good.
<daf> we have specific support for avatars in Gabble
<tomeu> anybody knows if the PS is already caching some info?
<daf> it uses hashes
<erikos> oh cool
<bemasc> eben: The only questions are about priorities, but I think that the Sugar team is good at getting priorities in order.
<daf> I think Salut is similar, actually
<daf> in fact, we had avatar support in sugar, but I think there were some PS bugs that made it problematic
<daf> so it got turned off
<erikos> daf: yeah seen code for buddy-icon
<tomeu> have you seen memaker?
<tomeu> a similar activity could generate svgs for using as avatars
<bemasc> eben: for the future, there is a question about handling multiple invitations
<tomeu> http://download.memaker.org/memakerVideo.html
<eben> bemasc: in what sense?
<bemasc> eben: I don't know quite how that's intended to work; but it's not urgent
<bemasc> eben: well, it seems like there's only one place for invitations
<bemasc> and so invitations must be handled in the order they were received
<eben> bemasc: Oh, no.  They just get appended to the activity tray.
<bemasc> ok
<eben> bemasc: The current design should work fine for some "reasonable number" of invitations
<bemasc> then what's the upper-left-corner flashy thing?
* homunq here, late as always (had a job interview)
<eben> bemasc: Ah, right.  So that's a *notification* of an arriving invitation.
<bemasc> ok
<eben> bemasc: There is only room for one notification at a time, but they queue up.  Once they "disappear", they should slide "into" the frame where they can later be accessed.
<tomeu> eben: you should add all these terms to walter's glossary
<eben> tomeu: good point
* HoboPrimate (n=Eduardo_@a213-22-205-215.cpe.netcabo.pt) has joined #olpc-meeting
<bemasc> eben: ok. Notifications are displayed in order, but all invitations are shown side-by-side in the top frame. Nice.
<eben> bemasc: right
<homunq> they are in the frame, not in a pallette from the frame?
<homunq> how do they time out then?
<eben> homunq: That's right.  Each invitation has a palette with details, and action buttons.
<homunq> is there a broom?
<eben> homunq: They can just as easily be removed from the tray in the Frame as from a palette.
<homunq> yes, but what is the plan for timeout/manual removal?
<erikos> eben: this is the AlertBox you are referring to in the Todo?
<tomeu> right now, notifications disappear after 3 or 4 seconds
<eben> homunq: In fact, if we do impose timeouts on invitations, there would be a "remove" notification first, giving a last chance to look at it.
<tomeu> but an event can cancel them earlier
<eben> homunq: manual removal is accomplished via clicking the "accept" or "decline" button on the invitation.
<tomeu> oh, removing notifications or invitations?
* eben requests a timeout for explanation. :)
<homunq> I would vote for a global broom for all notifications. (invitations just a special case of notifications)
<homunq> um... which would go in the (wait for it) frame device of the frame!
<tomeu> ctrl-alt-del ;)
<homunq> :(
<eben> Here's the deal.  Notifications are *transient* objects.  They appear in a given corner of the screen for a brief time, queueing as necessary, and then go away.
<eben> They have 3 forms.
<bemasc> homunq, tomeu: maybe it's important that invitations disappear if the shared session to which one is being invited ceases to exist
<eben> 1) appear, and then slide into the frame.
<homunq> ah ok notifications do not persist after "sliding into" the frame, they are gone forever.
<homunq> that is what I did't understand.
<eben> 2) slide out of the frame, and then disappear
<homunq> sorry
<eben> 3) slide out of the frame, and then back in
<tomeu> bemasc: yeah, the component that created the notification can remove it before it times out
<bemasc> tomeu: not the notification, the invitation
<homunq> I was confused notif/invit
<tomeu> ouch
<tomeu> homunq: but the same ;)
<eben> in all cases, a notification is directly associated with some object in the frame.
<bemasc> If A invites B to a shared activity, but B doesn't respond, and then A goes home, the invitation in B
<eben> In most cases, the notification will represent the arrival or departure of the associated object.  In some cases, such as low battery for instance, it will simply indicate that an object in the frame wants attention.
<bemasc> 's frame should probably disappear
<homunq> yes but their content does not persist, just the change of state that they signify.
<eben> This last point is where the design for the "alertbox" comes in, since we need a way to indicate that it wants attention in the Frame, and need a way to convey the associated alert.
<homunq> so the question is, does any object that sends a type-3 notification start to pulse?
<eben> homunq: 3) slide out, pulse briefly, timeout, slide back in
<homunq> no the object in the frame. is it still pulsing when you say "hey I missed that, what happened?"
<eben> homunq: The question then is what happens to the object icon *in* the Frame once the notification goes away, to let you know that it has something to say.
<homunq> yes
<eben> homunq: The current design is shown here: http://wiki.laptop.org/go/Specifications/Object_Transfers
<eben> (third image)
<homunq> OK good.
<eben> Right now, we have a badge (there are a few types of badges, eg. alert, notify, question, etc).  And any object with a badge gets a modified palette, with an "alertbox" section, which conveys the message.
<eben> So the hard parts to define here are how this alertbox functions.  Is it a part of the palette that you can invoke with a certain method/property?  Is it another widget that you can embed yourself into anything?  How do we make it easy to modify the available actions on the palette in conjunction with the alert?  etc.
<eben> (Sorry for dragging us immediately down this path....I still want to entertain questions on the rest of the list, and attempt to get a rough set of priorities as well!)
<homunq> I think that the alert should be an entire self-contained palette of its own?
<homunq> I mean, it should include all associated options?
<eben> homunq: The problem is that the default set of options may be irrelevant given the alert.
<homunq> based on the idea that it will mostly want to change available options.
<homunq> that is what I mean. replace the whole palette.
<homunq> just an idea
<eben> homunq: consider an activity that fails to launch.  It might offer to show you the logs, or cancel
<erikos> eben: when the alert is up the other options should maybe be hiden
<erikos> eben: or it is modal to the palette
<eben> erikos: Right, my mockups currently take no technical concerns into account, but do simply show "everything that's relevant" from the default palette and the alert, and nothing else.
<homunq> that is what I mean, a whole drop-in replacement for the palette. No normal options.
<homunq> if it is related, you can use a subclass or something.
<eben> erikos: Basically, it amounts to 1) retaining the standard palette 2) adding the alert box 3) temporarily replacing the options_menu with an alert_options_menu
<bemasc> The information you'd want to show on failure depends on the thing that has failed.
<eben> homunq: Perhaps, but consider being the receiver of a failed object transfer.
<eben> homunq: The palette in that case includes the file info, the type, a preview, etc.
<bemasc> So there's really no way around making different failure palettes for every case that uses them
<eben> homunq: It seems relevant to retain all of that even when it fails.
<eben> Maybe that is the best solution.  In cases as I just described, they could duplicate the effort and put the same widgets in both palettes.
<bemasc> some widgets will want to go in both palettes, and some will not
<eben> Underneath, that approach seems to naturally suggest that the alertbox is not tied to the palette class at all.
<bemasc> clearly a "pause download" button doesn't make sense after failure
<bemasc> but "amount downloaded" still does
<tomeu> are you discussing how to share code between normal and alert palettes?
<eben> bemasc: Right, note that I was always considering the list of all actions to be separate from the other content....but even so.
* tomeu a bit lost
<eben> bemasc: the actions list would be swapped out in either case.  It's a question of the "non-action items"
<erikos> bemasc right - where it stopped is useful information
<erikos> eben: what about making buttons that you do not need for the alert inactive?
<bemasc> oh
<bemasc> tomeu: yes
<eben> erikos: in palettes we never show inactive ones....we just omit them, I believe.
<eben> erikos: and it only makes sense to do that anyway if they might later be made active again.
<tomeu> pygtk has good enough ways to achieve that, you should not worry
<eben> In some of these cases, that might not even be an option.
<homunq> ok, not worry.
* homunq wants to talk about signing/updates sometime.
<tomeu> homunq: me too!
<eben> OK, so for argument, let's assume for now that the approach we take is to require swapping out the entire palette.
<eben> We could a) create an AlertBox class that users can embed inside a new palette object.
<eben> Or b) create a subclass of Palette, AlertPalette, which automatically handles the layout and formatting given the necessary properties.
<bemasc> eben: (aha! amount downloaded makes sense, but estimated time to completion doesn't, so even non-action information should change in the failure dialog)
<eben> In either case, the developer would be responsible for handling the "swap" of the palettes, using set_palette() on the associated button.
* gregdek (n=gdk@nat/redhat/x-8976d9b39f534200) has joined #olpc-meeting
<eben> bemasc: good point.  agreed!
<erikos> so i guess swapping completely makes sense
<eben> What do people think of the above outline, and is (a) or (b) the cleaner option?
<homunq> weakly a)
<bemasc> AlertBox would allow non-fatal alerts
<eben> bemasc: they both would, no?
* HoboPrimate has quit ("Leaving.")
<eben> In my mind it's just an API question.  Do you pass the needed args to the AlertBox class and then embed that in the palette manually, or do you just pass everything to a subclass of Palette?
<erikos> bemasc: you mean alerts where you do not have to swap all the information?
<eben> Naturally, (a) offers the possibility of embedding these alert boxes in other places as well.  erikos, perhaps something like this could be used in the control panel as well...?
<bemasc> eben: yes... AlertPalette has the advantage of permitting a total restyle on the basis of failure.  So, alert palettes could be bright yellow, and showing them could cause a alarm noise.
<bemasc> eben: or something less extreme.  AlertBox allows the developer to use the Alert style for "warnings" in dialogs that otherwise represent success, without worrying that the style of the entire dialog might be different
<erikos> eben: well we have an alert api already
<eben> erikos: I'm talking about the "inline alerts" we discussed...
<eben> erikos: for revealing info within the details of a module, contextual to the controls.
<erikos> eben: hmm ok i see
<eben> bemasc: in a sense, yes.  The three badges we have so far for the alert, in either case, are warning (triangle with '!' inside), notification (square with '!' inside), and question (square with '?' inside)
<eben> they, in turn represent a failure/warning, a success, and an uncertainty
* tomeu likes a) better
<erikos> eben: not so sure the alert itself changes if contextual to a control or an 'event'
<erikos> eben: i agree that we should generalize the alert API if we can not make this alert fit in there as well
<erikos> in principle we should have: icon, title, message, buttons in all the cases
<eben> erikos: Yeah, I'm not positive it will be the right solution for both purposes, but it's about how I would have mocked it up.  Perhaps the title is optional, so for the inline alerts you just get the icon and a single line of text.
<eben> erikos: not true.  In the above (a) approach, the alert box is independent of any buttons/options
<eben> erikos: those are part of the palette itself.
<eben> erikos: So we actually have type_code (icon), title, message
<erikos> eben: the retry option is dependent on the same event no?
<erikos> eben: even not in the same box
<eben> erikos: not sure what you're asking...
<erikos> s/retry option/retry button
<eben> Oh, in the transfer mockup?
<erikos> yup
<eben> dependent on the same event, of course.
<eben> erikos: But the point is that the entire Palette, under this scheme, is dependent on the event.
<erikos> eben: and the alert is the title+message+icon 
<eben> erikos: The developer would have created some alert_palette = Palette(...), and then embdded an AlertBox object and attached a set of MenuItems to it.
<erikos> eben: this would work with the current api
<eben> The "AlertBox", in my current thinking, is just the stuff shown in gray in that palette.
<erikos> yup - that works with the current alert api
<erikos> (just the colors need to be an option)
<eben> erikos: Right.  The only thing it probably does require is the ability to set the content before and/or after the menu independently.
<erikos> eben: what i mean in the end is:
<eben> Which the API currently doesn't support, but we only cut it in order to define it clearly first.
<erikos> eben: you mean the palette API right?
<eben> erikos: yes
<erikos> eben: ok ;)
<erikos> so to produce the output shown in the mockup we can combine a palette with an alert basically
<eben> erikos: yup, basically.
<eben> so, the process would be, to sum up:
* dirakx has quit ("Leaving.")
<eben> An object transfer error occurs. I create a new palette and embed an alertbox in it.  I create a notification object.  I attach the new alert palette to both the notification and the transfer object in the frame.
<homunq> sounds reasonable.
<eben> Then, upon the cancel/retry button callback: I make sure that the notification is gone.  I reattach the old palette.  I take the appropriate action.
<erikos> homunq: only wants us to finish :p
<homunq> :P
<erikos> eben: sounds good to me
<eben> Alright.  So, todo items are a) create an AlertBox class b) add support for more complex layout to Palette class
<eben> Onward!
* homunq /me /me ???
<erikos> +1
<erikos> homunq: let me see the list for today :p
<homunq> OK. My basic proposal is up at http://wiki.laptop.org/go/Talk:Activity_bundles#Related_proposals
<homunq> There are a number of related issues.
<homunq> auto-update and signatures
<homunq> key management for the above (punt)
<homunq> associating "same" activity in UI
<homunq> (which I have a proposal for but I do not intend to implement it right away.)
<tomeu> I'm not sure how useful is relating bundles that have different signing-keys
<tomeu> treating it as different activities may not be so bad
<homunq> security for who can see same instances (my dream situation, which I haven't written up, would involve private journal entries)
<homunq> tomeu: that is why I do not intend to implement that part, but I think it is good to agree on a plan.
<homunq> sub-issues: adding translations without breaking signatures
<tomeu> ok
<homunq> -interaction with "favorite" attribute of activities.
<homunq> oops that link I gave is below my proposal, just scroll two sections up to read it all.
<homunq> I think that the first question is auto-update and security for same.
* _bernie (n=bernie@dyn-248.woodhou.se) has joined #olpc-meeting
<homunq> My impression is that there is general agreement that there should be a single key for a given activity, that a certain amount of lost continuity when that key changes is OK.
<tomeu> yup
<homunq> Note that much more sophisticated key-management systems are possible (SPKI-like) but the only gain for those is if you have a list of which private keys are protected by somebody's sugar (one per XO)
<homunq> In other words, a way to talk to school servers and ask them "do you recognize this as an XO"
<homunq> that is way out-of-scope right now.
* _ypod_ (n=ypod@wireless-19-26.media.mit.edu) has joined #olpc-meeting
<homunq> So, the only open questions here are: do we explicitly use version numbers as a proxy for anything else (file formats, network protocols, config data formats)?
<homunq> I would argue that making such data optional in the activity.info would be reasonable. (minor version number = network compatible; "I can read files since version x"; installer never just copies old config files, but puts them in a accessible directory with their version number.
<homunq> ...
<homunq> Next question: associating "same activity"
<homunq> as tomeu says, this is not urgent.
<homunq> but read my proposal, since I expect to use version number and signing key as input to help determine this.
<homunq> ...
<homunq> final question: implementation.
<eben> homunq: well, hang on, there.  I think that grouping by key is something we should try to have sooner than later....
<homunq> what do others think? Possible in U2?
<morgs> Well, how long do we have? :)
<eben> homunq: I envision creating a group of all activities having the same key, and ordering them by version number within those groups.  This is a mockup I'm working on at present, and intended to update the designs on the wiki with soon.
<erikos> morgs: i read somewhere today 3-6 month
<tomeu> morgs: 3-6 months ;)
<homunq> eben: I think threading is key.
<tomeu> that's better than 1-12 months :P
<homunq> I mean, handling forks.
<eben> homunq: I'm not sure I agree with you on that.
<eben> homunq: A fork is effectively a new activity, unless it's signed with the same key.
<morgs> +1
<homunq> two cases: switching key, no fork
<homunq> switching key, fork
<homunq> I think you have to deal with 1
<homunq> so you can't avoid 2
<eben> homunq: but switching key *is* a fork, for us, right?
<homunq> I also think that by dealing with 1 painlessly, you increase security.
<eben> homunq: In that there are no guarantees at all about where it came from if it doesn't have a key we know.
<homunq> because people will not feel pressure to be promiscuous with their keys.
<homunq> eben: basically, true.
<homunq> no guarantees.
<homunq> but it should still be associated in activity list, or things will get confusing.
<eben> homunq: And I disagree.
<homunq> (currently I have 3 journals in my frame on my XO. screens apart. confusing.)
<eben> confusing....well, maybe a little...but less so than thinking that every "Browse" activity in my list is effectively the same thread.
<eben> homunq: we *want* to treat them independently, giving each key its own group, to encourage kids and developers to give activities unique names/icons when appropriate.
* gregdek is now known as gregdek_gone
<homunq> "Can I have the signing key for email?" "no" "but then my users can never figure out how to move over!"
<eben> homunq: but when they don't, we still need to make sure that they don't get mashed into one ball that the user thinks they can trust.
<homunq> vs.
<homunq> "Can I have the signing key" "no, you have no reason to even ask"
* tomeu goes eat something
<eben> homunq: If person B has direct communication with A, and they agree to be working on the same activity "thread", then A has no reason to say "no".
<homunq> ???
<homunq> email is a good example. Very private data, high likelihood of development/desire for forks.
<homunq> if it were my activity, I would not give out the signing key like candy.
<eben> homunq: On the other hand, if A wants to keep his identity, and does wish to say "no" to B who is trying to get his descendent work out there, it should *not* appear as though it is the same as A's.
* |ypod| has quit (Read error: 110 (Connection timed out))
<homunq> There are many cases when I would trust somebody to code with it, but not to guard it well.
* mvn071 has quit (Remote closed the connection)
<eben> homunq: then B should give all his patches to A and let A sign and distribute it.
<homunq> absolutely, agreed, should not appear the same. which is precisely WHY it SHOULD appear together, it is the only way the OS can give useful tips on how (not) to trust it.
<homunq> My point is also that, the more gently we can treat continuity breaks, the less people will subvert security to avoid them.
<homunq> I do not want your average activity to be named "homunq's Develop", but when it is in a thread and it is not your favorite version, you can put that on there to distinguish.
<eben> homunq: OK.  Well I guess I'll finish my mockup the way it lives in my head and we an talk about it from there.
<homunq> or something like it.
<eben> homunq: so, what's the tie that allows you to group them if it's not the key?
<homunq> in activity.info (or some other file in activity dir) a list of prior keys with version of fork.
<erikos> looks like there is not so much agreement here :p
<erikos> do we want to leave it here for today?
<homunq> yes, I am not implementing that part now anyway.
<homunq> But I do propose to implement the key and signing part,
<homunq> which is why I want comments on that part. http://wiki.laptop.org/go/Talk:Activity_bundles#Signatures
<homunq> Not mentioned there: the problem of "how do I store the private key".
<erikos> ok, homunq so you want to explain that in the topics section?
<erikos> so i can get that in the mtg minutes
<homunq> topics section???
<erikos> http://wiki.laptop.org/go/Sugar_dev_meeting#Meetings
<homunq> OK will do. Meanwhile you guys read it and comment?
<erikos> i want it in the minutes that others not here today can comment as well
<morgs> homunq: sha256 hexdigest would be better than base64 encoded - since you can sha1sum on the command line to compare manually if you like
<homunq> OK.
<morgs> homunq: one signature per bundle? surely just a file then, rather than a directory
<homunq> room for growth.
<homunq> starting with, signatures for TRANSLATABLES
<homunq> (assuming that you may eventually have a list of trusted translators)
<morgs> homunq: keep in mind two acronyms: YAGNI and WHUI.
<morgs> You Ain't Gonna Need It, and We Haven't Used It.
<homunq> premature optimizations?
<morgs> I suggest a single signature per bundle, with the translation stuff as a future feature
<homunq> this is a bundle format. we want tools to work stably.
<morgs> homunq: OK then, make allowances but don't slow down the development of the first version
<homunq> I can think of 3 good uses for having it be a directory, just off the top of my head. Not too far in the future.
<morgs> OK
<homunq> translatables, key management, and secondary unofficial signatures (testers)
<homunq> yes, for now just a dir with one file.
<morgs> homunq: perhaps we should discuss this separately with people like m_stone etc - but I'm interested in the algorithm and signature format stuff.
<homunq> OK. Other comments?
<erikos> not from my part for now
<homunq> I plan to start work on this stuff this week.
<homunq> The only part I do not have a clear plan for is, as I said, how to keep the private key.
<homunq> I wish that there was journal support for privacy/encryption.
<homunq> because adding that to my plate too ....
<morgs> homunq: Let's talk to m_stone about that.
<homunq> Good idea.
<homunq> Anybody here have any super-simple stopgaps to propose?
<homunq> If not, move on.
<erikos> ok i think then we are done for today
<erikos> thanks for joining in everybody
<eben> erikos: OK, any further questions and prioritizing of my list can happen in mailing lists. :)
<erikos> eben: oh you wanted to do that now?
<eben> erikos: Nope.
<eben> Well, I'm open to more questions now.  But prioritizing can come along later.
<homunq> I put up my version of the discussion in minutes ; http://wiki.laptop.org/go/Sugar_dev_meeting#Topics
<erikos> wasn't meant to interrupt - thought that people slided off already
<erikos> homunq: great! will get into the email minutes as well - so we grab further attention
<eben> erikos: Yup.  See you back in #sugar!  He heh. :)
<erikos> eben: wait.... :) 
<eben> erikos: ok
<erikos> yup see you guys in sugar - 
<erikos> eben: no was kidding 
* eben (n=eben@wireless-233.media.mit.edu) has left #olpc-meeting