[21:46] sorry, network trouble [21:48] okay, _now_ i'm really here [22:27] ...and now we're here. [22:27] yay! [22:27] i have almost figured out what i was thinking with xsd class factory [22:28] so, requirements first? [22:28] ieieh eretheeeeee eeeeeeezz [22:28] someone is playing with my keyboard. :-) [22:28] yes [22:28] oh my [22:29] did someone get that good stiff drink she was talking about? ;) [22:29] no, she had some "tea" [22:29] oh well :) [22:29] so, got requirements.txt open? [22:30] y'all take notes, if that's cool [22:30] er, hang on, getting the font size big enough [22:32] ready [22:33] ok [22:33] so, lets just go through each section [22:33] how about model, down to user roles? [22:34] (e.g. we haven't talked about load sharing) [22:34] (but i put it in) [22:34] we should change it if it isn't right [22:35] hang on, I'm not sure if I've read this before [22:35] i doubt you have [22:35] i just wrote it this weekend [22:35] i was trying to use the mind meld device [22:35] but now we need to finish the process [22:35] of mind melding [22:36] ok [22:37] ok, read that part [22:38] but how does it sound? [22:38] does it match what y'all were thinking? [22:38] doesn't sound bad; what's this about load sharing? [22:39] well, if we do load sharing, things get all complicated on the server end [22:39] hee hee [22:39] so i thought maybe we could just punt for the first release of v1 [22:40] especially since we personally know all our users [22:40] yeah; do you think load balancing is something we'll need? [22:40] they could probably all use one server [22:40] :) [22:40] not really [22:40] ok [22:40] I'd leaving it out entirely [22:41] ok. slash & burn, baby [22:41] (your end is the note keeping) [22:41] I'll do edits and check it back in when we're done [22:41] great [22:41] ok, are we all good down to user roles in the model section? [22:42] yes [22:42] k so down to SERVER [22:42] Can a consumer make queries? [22:42] yes [22:42] ok, cool; that supports the role stuff we'd talked about [22:42] oh, do you mean like construct some & save them for later? [22:42] Why is there a distinction between an owner and an author? [22:43] Dym, you should show diagrams from last night to ara so she can see the other role things [22:43] the owner can change privs for the model [22:43] I didn't mean that, but we may want to think about allowing that some howI think we'll need to dive into the "what can we do to support these use cases stuff" [22:43] ok [22:44] in a large group maybe there are some people who are trusted to work on the model but not to say who can see it [22:44] ok [22:45] it seems like Owners should automatically be authors; it's a bit silly to not have them be authors, given that they can make themselves authors; why wouldn't we want to do that? [22:47] hmm, i dunno [22:47] doesn't really matter to me one way or the other [22:49] (can you note that query thing as an unresolved issue? i think we should come back to it after the theory is more settled) [22:49] so, if you make that change to owners, are we good down to server? [22:49] Steph's opinion is that Owners should also be Authors; (one should be a superset) -- I think I agree. [22:50] yes [22:50] great, change it [22:50] We're looking at the diagrams right now [22:50] oh, ok. lemme know when you're ready [22:50] Steph mentioned that we're showing two things by the lines in the dep diagrams, both strict dependency and data flow [22:51] i.e., in the simple dep diagram, attacks don't need to depend directly on design because they also depending on things which depend on design [22:52] mmm, i see [22:52] can you fix it somehow? [22:52] i think those links are important [22:52] maybe they are only data flow? [22:52] yeah; I think a different link color or something might be in order -- I'll poke at it later [22:53] i.e. we shouldn't think of it as a dependency at all, maybe [22:53] cool, sounds good to me. i am sure you will come up with something great [22:55] Dymara would be a good name for a character in a fantasy novel [22:58] (you are going to tell me when you're done w/ diagrams, right?) [22:58] yeah [23:00] yeah, I'm going to name my first child dymara, I think [23:00] test [23:01] um, so, [23:01] woot [23:01] i thought neither of you were having children... [23:01] sorry, :D playing w/ dyms computer [23:01] we've decided that maybe we'll have one together [23:01] Action: asparagi laughs [23:01] wow [23:01] well, they'd be awfully cute [23:02] call it dymara triking somethingorotherelse [23:02] Action: asparagi laughs so hard it hurts [23:02] Action: asparagi is still laughing [23:02] ok, I think we're done with the diagrams -- we may want to rename business rule attacks to requirement attacks [23:02] sure [23:02] well, maybe [23:03] i don't people to think they are attacks on the requirement for 95% uptime [23:03] business logic attacks? [23:04] hrm [23:04] well, if we use requirements the way we've been meaning it, it makes sense, but maybe you're right [23:04] we could brainstorm a bunch & send ideas to the list? [23:04] yeah [23:05] k, so SERVER down to the roles part [23:09] it's bad to kill your emacs buffer when you're in the wrong window. [23:09] Shouldn't that be Dymara Triking? [23:09] Yes, let's talk about servers [23:09] Well, we are triking right now, so that bit was kind of redundant [23:10] so, how's it sound down to roles? [23:10] up to users sounds good to me [23:11] k, user roles part? [23:13] why are we using different names for administrator vs owner; it seems that using the same name might make more sense, as the only difference is scope [23:14] i guess i was imagining someone trying to administer the server perhaps having trouble with the concept of "server owner" vs. "model owner" [23:14] so i thought giving them different names was a feature [23:14] the part about not being able to gain read/write access to existing models isn't too clear; it seems like a server admin should be able to do that. [23:14] but again, i don't have strong feelings either way [23:15] i think they shouldn't, because then multiple groups who don't trust each other can all use one server [23:15] as long as they trust the sysadmin for the server, they don't have to trust each other [23:16] & they don't have to create a bunch of identical accounts for different consultants in different groups, & we don't have to write anything that does groups [23:17] well, they still don't have to trust each other; the server admin could assumably own their models regardless, but as the creators can't own an existing model regardless [23:18] that didn't parse, try again? [23:18] as long as model authors/owners can own/author multiple models and assignd access to them from the same set of users, we still don't need groups [23:18] got it, and i agree [23:19] hostile groups can still share a server as long as they trust the admin regardless of whether or not an admin can become an owner on an existing model; they have to trust the admin regardless. [23:20] they have to trust the host admin, but we don't have to make them trust the Trike server Administrator role [23:20] each group could have their own Administrator [23:20] and the other groups wouldn't have to worry [23:21] the other groups only need to trust the host sysadmin [23:22] well, okay, they still have to trust other Administrators not to delete their models, but that's a little different [23:22] hrm [23:23] We could allow/force the creator of a model to assign one or more admins to the model, and allow them to recover privileges [23:23] hrm [23:24] but isn't that the same as just having them be owners [23:24] ? [23:24] I guess I'm not convinced this is a really important thing for us to support; do you think it is? [23:24] Action: asparagi shrugs [23:24] hrm [23:25] i guess if i were designing a pie-in-the-sky system i would want it to work like this, and it doesn't seem any harder to implement [23:25] in fact really, it's easier. [23:25] and it goes along with conf & integ being more important than avail [23:26] that said, i'm not at all set on it [23:26] hrm [23:26] feel free to change it [23:26] can we table this and talk about it on the phone next time? [23:26] it is way more important to have a documented picture of what we want than to have this particular thing any particular way [23:26] I think it's a bit too nuanced for irc. [23:27] ok [23:27] sure, that works too [23:27] so, down to CLIENT? [23:28] yeah [23:29] do we want to spec a keyboard-only ui? [23:30] Action: asparagi is unsure [23:30] that seems like it could be useful [23:30] can we please pretty pretty please make trike accessible to blind users? [23:31] pleaaaaaaaasssssseeeee??? [23:31] nope [23:31] yeah, it does [23:31] Action: DymAraThe2nd grins [23:31] and to think, I'm the half of the DymAra brain collective that's been drinking [23:31] you just wanted to see what happened when i didn't like a suggestion :) [23:32] so you could calibrate [23:32] ;) [23:32] Action: DymAraThe2nd pouts a little bit and puts his/her three mice back in his/her pocket [23:32] 3 mice? [23:32] oh [23:32] see how they run [23:32] got it [23:32] sure, rewrite that puppy so we don't need a pointing device [23:32] three mice might be kind of handy for the drawing bits... [23:33] god knows how we will pull this off [23:33] yeah, I'm not sure either [23:33] "now, grip the 3rd mouse with your left foot, and..." [23:33] I don't think it should be a requirement right now; it might need to be an alternate UI entirely, but I think we may want to keep the idea around. [23:33] control-alt-meta-hyper-super-left_foot-Q! [23:34] or perhaps offer free arm grafts to peoples foreheads for advertising trike [23:34] wow. that should launch the space shuttle or something [23:34] soon you'll need to be an octopus just to use it. [23:34] everybody wants prosthetic foreheads on their real heads [23:34] "trike v3: now with more arms" [23:35] so, is keyboard-only in or out? [23:35] ok, client looks good; I'll add in a noted about revisiting keyboard-only later [23:35] (for this client) [23:35] great [23:35] k. so, protocol [23:36] looks good to me [23:37] deployment? [23:37] hard to disagree with, really [23:37] yeah [23:37] file formaz [23:37] er, t [23:38] sounds good. [23:38] k, users [23:38] can we specify that users are computer savvy? [23:38] I think I'd like to include that in all my programs. [23:38] i.e. s/reasonably// ? [23:39] It's more that we want to state it as "we are only intending to support computer savvy users" [23:39] Great, ship it. [23:40] are we ready for workflow? [23:41] The auth bit in user is a bit weird [23:41] are we implying that we'll reauthenticate for users and store their creds? [23:41] because it sort of sounds like that [23:42] no, i think we're implying that we want to use something with a similar effect to that [23:42] e.g. same client cert gets you in to multiple servers [23:43] (can you have one client cert with sigs from multiple CAs?) [23:43] yeah, it's weird, though. [23:43] do you want to rewrite it, or take it out, or..? [23:43] I'll clarify a bit [23:44] ok, workflow [23:44] i mean, i feel like there are good reasons to use certs vs. passwords, and i was trying to put something in the requirements that made the certs seem reasonable [23:44] Action: DymAraThe2nd nods [23:44] oops, sorry, not to reopen closed topics [23:44] workflow [23:44] that's ok [23:46] I guess there may be a bit of a conflict b/w immediate change and atomic transactions. [23:46] unless we define atomic transactions a little better [23:46] so, multiple users and the bit about user-created data hanging around gets weird [23:46] why? [23:47] stephs's proposing that that be client functionality [23:47] undo does, too [23:47] if i create something, and then somebody else thoughtlessly nukes it due to some other model change, i'd like a way to get it back [23:48] ok, yeah [23:48] doing that on the server seems really expensive [23:48] time, or space, or...? [23:48] i don't see the expense [23:49] hrm [23:50] undo is a little interesting, too; let's finish with nuked data first [23:50] yeah [23:50] i guess for one thing, i'm not expecting that much user-created data to be nuked in practice [23:51] i think by the time we have this done, there will not be that much user-created data to start with [23:51] I think that we were thinking of that as a per-user thing that might happen more often when we were thinking about expense; it sounds like it won't be as much of a problem [23:51] yeah [23:51] especially user-created data hanging off generated data [23:52] ok [23:52] ok, are we ready for undo? [23:52] yes [23:52] k. so it seems like when i hit undo, i want to undo my last change, not yours [23:52] yes [23:52] exactly [23:53] but if i change, then you change, it gets a little iffy to roll back my change [23:53] yeah [23:53] because what i was going to unchange might be in the salvation army pile [23:53] this is kind of why I like the design history thing; I think we may need something a bit more intelligent than a traditional undo [23:53] yeah [23:54] so i feel like maybe we could have the server give the client an undo handle or something [23:54] but the server would actually do the undoing [23:54] if possible [23:54] or something [23:54] Steph is tired and heading out [23:55] maybe we should mark this for further discussion [23:55] g'night steph! [23:56] yah, i was thinking i left out something like knowing later who changed what, too [23:56] Action: Dymaxion nods [23:56] I'll add notes about what we're talking about right now and we can take it up next week [23:56] that is sort of related to the design history thing [23:56] k, sounds gooe [23:56] i am really close on the xsd class factory thing [23:57] yay [23:57] steph said something re: wishing those diagrams were in svn [23:57] yup, they're going to be; the visio too [23:57] i know they are generated.. [23:57] ok. awesome [23:58] yeah, i think i found & nuked some of the vestiges of the old design for xsdcf [23:58] Cool [23:58] maybe now it will load w/o barfing [23:58] hehe [23:58] of course the xml parser is griping about stuff i cut & pasted from the xsd spec [23:59] anyway, i can let you go [23:59] ok! See you later [23:59] night! [23:59] 'night [00:00] --- Thu Mar 23 2006