User:Bemasc/Versioning and collections commentary

(12:39:37) homunq: eben - I want to start coding new activity bundle format, do you have a minute to talk about your UI vision there? (12:39:55) eben: homunq: Sure, let's do it. (12:40:31) homunq: I think the main question is, is it worth including enough info to reconstruct "broken threads" (12:40:49) homunq: with forks being one case of the latter. (12:41:18) homunq: The UI I envision that becomes possible when you do (12:41:45) eben: homunq: Well, I still haven't been convinced that broken threads should in fact be reconstructed. I personally feel that a broken thread should be treated as a separate activity. (12:41:59) homunq: is that when a "newer" activity becomes available that crosses a break (12:42:27) homunq: the user has some easy way to explicitly update favorite version (12:42:36) homunq: and explicitly update instances. (12:43:07) homunq: newer version update implicitly within an unbroken thread (12:43:28) homunq: and you can explicitly say "use original version" if it is available (12:43:57) homunq: with aggressive backups of activity versions, so that if you have server coverage chances are you can get orig version. (12:44:24) eben: where the "original version" could be an activity on the other side of a break? (12:44:51) homunq: The principal reason I think that broken threads are worth it, is that it makes our security model more in-line with reality. (12:44:55) homunq: and thus more secure. (12:45:04) homunq: because people will not be subverting it. (12:46:03) homunq: original version could not be on other side of a break because the only way to cross a break is to open (12:46:12) homunq: and opening saves a new version of the instance (12:46:25) eben: But I disagree with it on the principle of allowing "just anyone" to create new activites based on existing activities which appear as "new versions" to the rest of the kids. (12:46:31) homunq: so only the old instance would have an old original version. (12:47:00) eben: OK. So consider activity A. (12:47:22) homunq: OK. exists in version Ax.1 (12:47:26) homunq: Ax.2 (12:47:30) homunq: Ay.3 (12:47:47) eben: right, perfect. (12:48:33) homunq: so you have an instance of Ax.1 (12:48:39) homunq: and then you get Ax.2 (12:48:49) homunq: instance automatically opens using Ax.2 (12:48:55) homunq: Now you get Ay.3 (12:49:03) eben: now, Bob comes along, guts A and derives Ay.1 (12:49:32) homunq: No... the rules would be that version number keeps increasing. (12:49:49) homunq: something derived from Ax.1 is Ay.2 (12:49:59) homunq: Or in our example Az.2 (12:50:03) homunq: because y is taken. (12:50:03) eben: homunq: But this is the point we disagree on. You say that it increases, because the "identity" doesn't change. (12:50:14) eben: I say that it starts at one, because it's effectively a new activity. (12:50:33) homunq: OK. So whose example are we following? (12:50:44) eben: homunq: Well, I'm trying to contrast them. (12:50:44) homunq: I say mine, because the burden of proof is on me. (12:50:52) eben: OK. (12:51:08) homunq: OK. So you get Ay.3 (12:51:33) homunq: now if you just run your instance, it still runs as Ax.2 (12:51:44) eben: Ax.1, Ax.2, Ay.3 (that's it so far, yes?) (12:51:57) homunq: but it has an extra button in the journal "update me" (12:51:59) homunq: yes (12:52:18) eben: OK. In other words, Ay.3 did not get auto-favorited, even if Ax.2 was already favorited. (12:52:35) homunq: and the palette or something on that button says "Ay.3 claims to be a newer version, but I cannot be sure" (12:52:59) homunq: or something of the sort - conveys the alleged nature of the relationship. (12:53:17) homunq: Exactly. (12:53:47) eben: OK. Is there a need for this button? Couldn't the kid just manually choose to open the instance with Ay.3 if they choose? (12:53:50) homunq: Favoriting and instances are two different (but related cases), I'm talking instances right now. (12:53:52) homunq: but yes. (12:54:24) homunq: Yes, they could do it manually, (12:54:34) homunq: but I think it is nice to have the button. (12:55:07) eben: And why do you think it's safe to tell the kid that this is a "new version"? (12:55:26) homunq: I think it is safe to say "claims to be a new version" (12:55:32) homunq: Note: (12:55:35) eben: How does it claim this? (12:55:44) homunq: implementation detail (12:55:47) eben: It retains the same service name, I guess? (12:55:52) homunq: no (12:55:58) eben: It has a new service name? (12:56:03) homunq: service name is not user-readable (12:56:15) homunq: it can have same or different user-readable name (12:56:17) eben: who cares if it's exposed. (12:56:34) eben: In your model, does Ay.3 have the same service name as Ax.2? (12:56:39) homunq: but it has a list of previous service ID's and version-of-fork (12:56:48) homunq: service name? (12:56:55) homunq: do you mean org.laptop.xxx (12:57:01) eben: homunq: Each activity bundle has a unique identifier. (12:57:01) homunq: or user-visible name? (12:57:02) eben: Yeah. (12:57:07) homunq: which? (12:57:19) eben: The unique bit, which registers it as what it is. (12:57:27) homunq: not same. (12:57:40) homunq: same in unbroken thread, changes in broken one. (12:58:23) homunq: unique is thus just hash, though (service ID, version) comes close. (12:58:36) eben: OK. So this is my point of contention. How is it proper to suggest to the kid that something with a) a new author and b) a new service name is a "new version" of something they already have? (12:59:03) homunq: OK. there is another bit I have to explain. (12:59:14) marcopg [n=marco@host145-118-dynamic.9-87-r.retail.telecomitalia.it] entered the room. (12:59:16) homunq: In my model, there are private instances. (12:59:26) eben: For that matter, how is it fair to the author of Ax.2 if anyone out there can come along and push (via suggestion) a "new version" out there which may be totally different, or buggy, or corrupt? (13:00:09) homunq: Any instance marked private cannot be opened by an activity which has P_NETWORK unless it has the same service ID as creator. (13:00:10) eben: I think that activity thread deserves to have a sense of ownership associated with it. (13:00:38) eben: Any instance that has not been shared? (13:00:45) homunq: I think that it is perfectly fair, if you give users explicit choice (13:00:51) homunq: and default is Ax.2 (13:01:06) eben: sorry, what's fair? (13:01:32) homunq: how is it fair to the author of Ax.2 if anyone out there can come along and push (13:01:34) eben: Oh, suggesting that Ay.3 is a new version of Ax.2? (13:01:38) homunq: yes (13:01:47) eben: No, I don't think that's fair at all. (13:02:08) homunq: I think that people sometimes want to assert that (13:02:17) homunq: and sometimes have good reasons for wanting (13:02:28) eben: I think you might get away with saying "Here's something (Ay.?) that claims to be an *alternate* version of the Ax.2 you have been using" (13:02:35) homunq: without having good reasons for getting the x signing key. (13:02:42) homunq: OK. (13:02:45) homunq: Alternate. (13:02:50) eben: Saying that something is a new version implies a chain of trust to me, and an authorship, which doesn't apply in this case. (13:02:55) homunq: that is good language. (13:02:57) eben: That's a really big difference. (13:03:26) homunq: Fine. (13:03:38) eben: To me, and it's why I personally like calling it Ay.1 (The first version of an alternate thread), even if it was based upon something else. (13:04:50) homunq: OK, but then what about Az.1 which inherits from Ay.1? How does it say that Ay.1 is a later ancestor than Ax.2? (13:05:15) homunq: That is what the monotonic versions are for. (13:05:31) bemasc: homunq: the key thing here, I think, is that eben is also proposing that instances be explicitly mime-typed (13:05:54) marcopg left the room (quit: "Ex-Chat"). (13:06:11) homunq: But is there any support for format versioning in mime types? (13:06:30) eben: homunq: I'm not sure....do we need full ancestry? (13:06:46) eben: (across threads, that is) (13:06:51) bemasc: homunq: so the type of an instance created by "Ay.2" is not "Ay.2". The type of that instance is "xml/tamtam-projectfile" (13:07:12) bemasc: homunq: if you change the format in an incompatible way, then you should introduce a new "mime type" to describe the new format (13:07:27) homunq: define "incompatible" (13:07:28) eben: If one thread simply uses monotonic versions and full ancestry internally, and perhaps also includes the thread it forked from, do we really have need for more? (13:07:31) bemasc: (possibly not actually "mime" format, but some kind of project file with type) (13:07:33) homunq: that is the problem for me. (13:07:42) homunq: if you add a new bit of data (13:08:05) bemasc: homunq: if it breaks the spec for that filetype, it's a new filetype (13:08:08) homunq: that does not break the old activity, but is not supported by it, how is that indicated in mime-type-land. (13:08:15) eben: homunq: incompatibility certainly comes as a responsibility, in my mind, of the author of the thread. (13:08:38) bemasc: homunq: that's the author's decision (13:08:41) homunq: but I think that most format changes are in the grey area of compatibility. (13:08:48) bemasc: homunq: that's why it's the author's decision (13:08:55) eben: homunq: Consider, for instance, taking Ax.2 (because you love the interface) and on purpose explicitly swapping out all of the data formats/protocols used for your own. (13:09:17) homunq: but it is a decision of whether it is totally different or totally the same, when the reality is neither. (13:09:39) eben: This is a case where, clearly, each thread can stand alone, but there is no intent to make the two threads compatible with each other...and why should there be? The are authored by two separate people who may not even know each other. (13:09:53) homunq: In that case, your new activity is not a child version (13:10:01) eben: homunq: But that decision can only be intelligently made when you restrict the scope to a single thread. (13:10:03) homunq: exactly, stand alone. (13:10:43) homunq: sorry - we are talking about two things. mime type and activity ancestry. (13:11:03) homunq: I do not want ancestry to be an archeological record of code origin (13:11:04) bemasc: homunq: ancestry does not imply compatibility. Witness MS Word. (13:11:50) homunq: if you change file formats incompatibly, you start a "new activity" (13:11:51) bemasc: homunq: and conversely, witness AbiWord, which is by no means descended from MS Word, but (relatively recently) got .doc import capability (13:11:58) homunq: even if it has same user-readable name. (13:12:18) bemasc: homunq: the question is: what can ancestry tell us? (13:12:30) bemasc: or rather, what actions can the system take on the basis of ancestry (13:12:59) bemasc: you're proposing one action the system can take on the basis of ancestry: determining which Activities are capable of opening which files (13:13:22) homunq: yes (13:13:31) homunq: and giving it as option for user (13:13:54) bemasc: another action the system can take is inheriting permissions. After some discussion at the "mini-conference", there was some consensus that if a future version of Activity is signed by the same key, then it should inherit the user's permission settings for that activity (13:14:03) homunq: not just using the ordinary "open with" but somehow giving that option more prominence. (13:14:17) homunq: agreed (13:14:24) eben: bemasc: yes, good point. (13:14:39) homunq: and signature-breakages do not. (13:14:42) homunq: obviously. (13:15:12) bemasc: homunq: so far, I still prefer explicitly typed instance formats (13:15:33) homunq: explicitly typed, but not versioned? (13:15:33) bemasc: and if you've broken compatibility with the previous versions, you should declare a new instance format (or increment your version format number) (13:16:03) homunq: mime types have a version number? (13:16:04) bemasc: homunq: versioned entirely separately from the activity bundle itself, and possibly with no assumption of backwards compatibility (13:16:14) bemasc: homunq: you can just add a number on the end, if you want (13:16:25) eben: OK....so activities that break signature, you agree, have new service names, do not automatically receive the same permissions, what else? I still fail to see an argument for treating it as a "new version" in the same thread. It's effectively a new animal. (13:17:04) bemasc: eben: homunq wants to use a non-secured ancestry system to determine instance compatibility (13:17:19) homunq: yes (13:17:33) bemasc: this amounts to declaring that the type of an instance is the specific version of the activity that created it (13:17:47) homunq: I also want it because I think that if we do not provide an un-secured (and thus un-trusted) mechanism (13:18:07) bemasc: and then another activity can declare "I can open that instance" by listing that activity version as one of its ancestors (13:18:08) eben: Wait wait....I find your last comment disagreeable, bemasc (13:18:09) homunq: I think that developers will feel undue pressure to use the trusted mechanism in inappropriate ways. (13:18:28) bemasc: eben: please explain (13:18:48) eben: If the type of an instance is 1-1 with its (activity,version) pair, then we don't have any kind of cross activity compatibility.... (13:18:57) homunq: bemasc is giving an accurate characterization of my position (13:19:35) homunq: for instances, no (13:19:40) homunq: just for files (13:19:51) bemasc: eben: in homunq's proposal, Activity B.8 can only read something written by A.3 if B.8 lists A.3 or later as an ancestor (13:20:04) homunq: instances (13:20:05) homunq: not files halish HoboPrimate homunq (13:20:10) bemasc: homunq: yes (13:20:22) homunq: that is my proposal. (13:20:29) bemasc: homunq: conversely, in eben's proposal, instances are handled just like files, in terms of typing (13:20:33) eben: that seems arbitrarily limiting, no? (13:20:58) homunq: note that multiple inheritance is possible. (13:21:00) bemasc: so A.10 can declare that it only reads a certain instance types, and the type written by A.3 might not be in that list (13:21:04) eben: What if these activities have no idea each other exists, but they share a common format? (13:21:14) bemasc: so then activity A.10 might not be able to open instances of A.3 (13:21:22) eben: They should "just work", and the system should know that they can handle each other's formats. (13:21:32) bemasc: eben: I agree, which is why I prefer your proposal (13:22:06) homunq: Sorry, one more detail. (13:22:07) bemasc: also, it could be that A.10 is a direct descendant of A.3, signed with the same key, so it should inherit permissions, even though format compatibility has since been broken (13:22:39) homunq: Ay.10 can say "I save in format Ax.3" (13:22:51) eben: it seems absurdly silly that a simple activity that writes a text file shouldn't result in something that can be opened by any other text editor created in the past or future. (13:23:07) bemasc: homunq: also, your system can be implemented easily inside eben's (13:23:07) homunq: eben: of course (13:23:18) homunq: that is why I keep saying "instances not files" (13:23:25) homunq: the text file can be opened (13:23:27) homunq: sorry (13:23:29) homunq: actions (13:23:39) homunq: actions = instances (13:24:36) homunq: but "I emacsed that" and "I wrote that" are not compatible. (13:25:01) bemasc: homunq: if you want, your Ax.3 can call its instance save format "Ax.3", and your Ay.5 can list "Ax.3" among the instance types it can resume (13:25:41) eben: homunq: Instances with all associated metadata and goodies? (13:26:01) homunq: eben: essentially, yes. (13:26:36) eben: Actually, I guess we haven't ever had the notion of an "instance type" to be honest.... (13:26:51) bemasc: eben: that's because we haven't had a distinction between files and instances (13:27:10) homunq: eben: not in reality, but in your new journal spec with actions it's pretty clear. (13:27:18) eben: Thinking about it, the whole idea was to treat the instance as having the type of the "primary file" object, such that one could say "open with X" and it would simply open that file in the new activity. (13:27:20) bemasc: eben: you specifically said that you imagined a scenario in which each instance was associated with a "project file" (13:27:54) eben: bemasc: Yes. I think each instance will have a "project file", and that project file will have a type. (13:28:06) eben: But in my head that type was TXT or PDF or PNG or HTML.... (13:28:13) homunq: eben: that makes no sense to me. An action can have multiple, incompatible files associated. (13:28:35) bemasc: eben: right, but TamTamEdit's project files are going to be some complicated custom format (13:28:38) eben: homunq: But it has to have a file which encapsulates those as a project. (13:28:49) homunq: Also, in my head, the instances/actions had some of their format in metadata (13:29:07) homunq: or is that abusing metadata? (13:29:13) eben: OK, let's try to tease this apart.... (13:29:28) bemasc: I think metadata should only be things that the user is invited to mess with (13:29:46) homunq: bemasc: OK granted. (13:29:54) homunq: screenshot? (13:30:01) homunq: not metadata then. (13:30:07) bemasc: homunq: changing the screenshot won't screw up the instance (13:30:33) eben: Sure, that's fair....metadata was to hold the state data which does not fit into the "well known file format" assuming there is one, or which the author doesn't feel is a necessary part of their new file format if it's not a known one already. (13:30:37) homunq: could be a security hole, and can't think of a positive use case. (13:31:29) bemasc: my rule of thumb would be, "the user should be able to write and delete metadata arbitrarily and at random without screwing up the instance when it resumes" (13:31:48) homunq: bemasc: that is a fair rule. (13:32:07) homunq: thus we need some other concept of quasi-metadata (13:32:10) homunq: for screenshot (13:32:12) eben: So, in my head at the time, the point of separating the actions from the objects was so that the metadata *could* hold the "extra" stuff, and so that it *would* be possible to say "open this instance with some other activity" because the file associated with that instance would be just a well known format of some kind. (13:32:14) bemasc: homunq: XML (13:32:19) homunq: for private signing key (13:32:25) bemasc: homunq: oh (13:32:27) homunq: OK that is implementation (13:32:40) bemasc: (I misunderstood you, never mind) (13:33:10) bemasc: eben: project files are almost always application-specific (13:33:27) bemasc: eben: the example in my head is Audacity (13:33:27) homunq: eben: I had thought the same as you (13:33:33) eben: bemasc: Umm, I think that's about a 50/50... (13:33:45) homunq: but now that we are being explicit, I like bemasc's rule of thumb better. (13:34:24) homunq: bemasc: I don't know much about audacity, what is the issue there? (13:34:33) eben: bemasc: sure, good example. So yes....in the case of an Audacity instance... (13:34:50) homunq: a project file has different sounds in it? like a concurrent playlist? (13:34:51) bemasc: audacity uses an XML-based project file format to describe the project itself, and also stores bits of audio in another directory that has like 1000 little audio files in it (13:35:00) eben: only audacity (right now) can read that file (even though others could read, for instance, the samples used or the rendered output of it) (13:35:14) homunq: OK. (13:35:19) bemasc: the project file format is specific to audacity, and is occasionally changed in a non-backward-compatible fashion (13:35:19) eben: But, there still is a file, and it still has a format, and other activities could certainly adopt it in the future. (13:35:21) homunq: good example. (13:35:46) homunq: that stuff clearly is not metadata (13:36:02) homunq: despite what eben and I vaguely thought (13:36:04) bemasc: So the question, for me, is UI (13:36:28) eben: It would be prudent for the creator of that format to keep all the necessary data for the project inside it, and to save other info (perhaps UI hints about the selected tab, the current view settings, etc.) as state metadata. (13:36:31) bemasc: If someone writes an Audacity-compatible Activity, what should users do to continue their work in this new program? (13:36:58) homunq: eben: why? (13:37:05) bemasc: Is that an example of resuming your work, or an example of starting a new instance? (13:37:06) homunq: why not keep the tab in that project? (13:37:25) eben: homunq: because that info is specific to the UI of the activity, and the platform that the activity runs on. (13:37:51) eben: I have audacity for OSX. It doesn't have tabs. It probably has a completely different and perhaps incompatible UI. (13:37:51) homunq: OK, so actions have 4 kinds of data (13:37:54) homunq: files (13:37:58) homunq: projects (13:38:03) homunq: view settings (13:38:07) homunq: metadata (tags) (13:38:11) eben: Consider likewise a painting program. Clearly you want the "project file" to be simply an image, for the best portability. (13:38:26) eben: Storing the currently selected color would be metadata. (13:38:36) homunq: I'd rather not assume that any of those are equivalent. (13:39:04) homunq: if an activity author wants to assume that, fine. (13:39:14) eben: (This, too depends....for instace, if an SVG editor decided to support .ai instead of .svg, then the color would be stored too, perhaps, as part of the actual project file....but that's all dependent upon the standards in place, or being set up in the case of new activities.) (13:39:29) homunq: but the model would be, keep 4 separate. (13:39:38) bemasc: eben: undo history (13:40:03) eben: bemasc: another interesting one....that would be part of the state too, right? (13:40:21) bemasc: eben: well, that's the question. An image editor clearly doesn't store the undo history in the image (13:40:29) homunq: in a perfect world, undo history would be in olpcfs ... (13:40:34) bemasc: homunq: I agree. (13:40:38) homunq: I'm actually kinda serious. (13:40:43) eben: homunq: I actually see 3 myself: associated files (of which one is the project), state blob, and metadata. (13:41:05) bemasc: eben: I'd like to work from the UI down (13:41:07) eben: homunq: in practice, the state blob might be some piece of inaccessible metadata. Well, needs to be. (13:41:38) bemasc: eben: As a user, I go to an instance and click "resume" or whatever. What happens? Am I shown a list of activities that can resume this instance? (13:41:39) eben: homunq: Sure, that would be great. But it's definitely not part of the file itself, right? (13:41:42) homunq: "inaccessible" is the point (13:41:53) homunq: this is different in some key way from normal metadata (13:42:01) homunq: the implementation can be the same though. (13:42:35) bemasc: eben: the PSD format stores undo history, I think, and so does gimp's XCF (13:42:43) homunq: bemasc: there is a "just resume" button, you click it, it defaults to something. (13:42:50) eben: bemasc: It resumes with the last activity you used. (13:42:50) homunq: you hover it, it gives you choices. (13:42:56) eben: (for that instance, of course) (13:43:04) bemasc: eben: ok. If there's a new version, does it use the newer version? (13:43:38) eben: bemasc: I would argue yes, if it is part of the same thread. (13:43:42) homunq: (new version AND new version can open that data) (13:43:48) bemasc: homunq: right (13:43:48) homunq: eben: agreed. (13:44:21) eben: Another potential option is to say that it uses the newest starred version, if there is a starred version in the thread, or the most recent otherwise. (13:44:24) bemasc: eben: ok. What if there are no more activities installed in the thread, but there is another activity installed that can resume it? (13:44:25) eben: Again, assuming it can. (13:44:26) homunq: so the data has a master file which gives it its format (13:44:46) eben: bemasc: In that case, we probably (currently) pick the next in the list. (13:45:04) bemasc: eben: what if I want to resume with a non-default activity? (13:45:09) homunq: currently, it is a mess. let's not go by currently. (13:45:11) eben: A better solution would be to present a modal dialog presenting the available options, including the option to attempt to recover the activity which created it. (13:45:37) bemasc: (or a non-default version) (13:45:40) eben: bemasc: If you want to do that you use the secondary palette of the resume button, which lets you choose anything that supports the type. (13:46:05) bemasc: eben: that all sounds pretty reasonable to me (13:46:15) homunq: eben: problem with that: (13:46:24) homunq: if you have 5 versions in the same thread? (13:46:26) eben: bemasc: One option for the non-default version case is to say that the list is actually hierarchical (one level) (13:46:30) homunq: they all clog up that list? (13:46:38) bemasc: eben: makes sense (13:46:51) eben: bemasc: If there are more than one version of an activity available, it could yield a submenu of the options, and indicate which of those are starred as well. (13:47:07) homunq: OK. (13:47:18) eben: homunq: No, the versions that are in an unbroken thread are treated as "one thing" until you ask for more info. (13:47:43) eben: This is the same as what I intended to represent in the activity list in home. They would be grouped by unbroken thread. (13:48:24) eben: But Ax.? and Ay.? would both appear in the top level list, side by side (well, depending on sorting...but assuming they choose to keep the same readable name) (13:49:01) bemasc: It sounds like the system has the following: (13:49:23) bemasc: each instance is a collection of files, one of which is declared the "main file". Each file has an explicit type. (13:49:36) bemasc: Each instance has "application metadata" and "user metadata" (13:50:05) homunq: There is only one issue this does not address... what if format tamtam-project5 can be opened imperfectly by tamtam-project3? (13:50:26) homunq: obviously tamtam3 cannot preemptively say this. (13:50:29) bemasc: the application can use application metadata as a convenience to store a small amount of simple data that is some how "not worth" putting in a file (13:51:05) bemasc: homunq: we could allow files to have multiple types (13:52:08) eben: bemasc: not worth or not appropriate (in the case of trying to adhere to already defined formats) (13:52:22) homunq: Other issue: what if different subfiles have different levels of privacy? (13:52:34) homunq: I am thinking about private signing key for an activity bundle (13:52:41) eben: homunq: hmmm, worst case, TamTam5 includes a way to export a TamTam3 file/instance (13:53:24) bemasc: eben: well, another solution (for a paint program) would be to have the instance contain "image.png" in PNG format and "mysettings.paint" which is a JSON file with activity-specific settings (13:53:29) bemasc: and make image.png the project file (13:53:30) homunq: But if I have an instance, and I have an app I like which opens tamtam3, but I do not have tamtam5 activity. (13:53:30) eben: homunq: That is a *really* tricky question....it's part of the reason that we didn't use aliases at all in the past... (13:53:55) eben: bemasc: instead of the state blob as metadata? (13:54:25) bemasc: eben: right, the "activity metadata" could easily be stored in a file other than the project file, without breaking compatibility (13:54:32) eben: bemasc: I think the goal is to prevent those kinds of "junk" files from accumulating, since the kids can also browse the objects as well. That's not meaningful as a file itself, to the kids. (13:54:46) bemasc: eben: JSON is fairly human-readable (13:54:59) bemasc: we could also adopt a "dotfile" convention like the one used in all UNIX systems (13:55:22) eben: bemasc: Well, sure, but in the interest of making it easy to browse through the objects one has created, seeing ever other one being a settings file would be obnoxious. (13:55:23) bemasc: hiding things from the user is generally bad, but the "activity metadata" would be hidden from the user anyway (13:55:46) eben: bemasc: That's true. We could hide those from the Journal if we built in support for it. (13:55:50) bemasc: eben: on UNIX systems, files starting with "." are simply not shown by default, according to convention (13:55:56) eben: Oh, I know. (13:55:58) homunq: bemasc: do you mean this: say my tamtam-3-editing activity can open all the other subfiles, just hand it that pile and see what it does with them? (13:55:59) bemasc: ok (13:56:15) eben: My point is the Journal has to add knowledge for that type of thing, if we do that. (13:56:18) bemasc: homunq: I don't understand that sentence (13:56:29) homunq: just a sec (13:56:42) bemasc: eben: yep, but the alternative is that the datastore has to handle an additional metadata system (13:57:04) bemasc: (this, by the way, sounds a lot like Core Data) (13:57:21) eben: bemasc: well, does that depend, too? How is it settable? If we don't expose it in the UI, does it matter if it's just normal metadata? (13:57:42) bemasc: eben: well, then the Journal has to have support for knowing what kind of metadata to show (13:57:50) bemasc: there's no way around writing code for this stuff (13:59:16) homunq: bemasc: how much do you know about Core Data? (13:59:33) bemasc: homunq: nothing. I read the wikipedia entry, though, and it sounds pretty nifty. (14:00:13) homunq: I read the wikipedia briefly, I could not tell if it was some way to keep undo stack, a layer above SQL, or what... (14:00:53) bemasc: homunq: it's a generic high-level data storage system (14:01:09) homunq: definitely has some relation to what we are talking about, but not clear if it has the answers. (14:01:25) homunq: OK, that is not the problem we're solving right now. (14:01:51) bemasc: eben: I think we're pretty clear on this. Develop can implement homunq's semantics over a simple per-file type layer (14:02:12) homunq: Let's reiterate: (14:02:14) bemasc: and the Journal just needs to know which of the files in each instance is The Main File (14:02:54) homunq: the main file = does not show in file list, just in actions list? (14:03:03) homunq: or is that a flag? (14:03:16) homunq: whether it shows or not? (14:03:21) bemasc: homunq: I don't follow (14:03:51) homunq: there are two views (14:03:52) homunq: actions (14:03:53) eben: Just an ordinary file (14:03:54) homunq: and files (14:04:10) eben: homunq: The main file might just be The Image, or perhaps The Text. (14:04:12) bemasc: homunq: "The Main File" is the "Project File". It's the file that defines the instance. (14:04:22) homunq: if the Main File is essentially synonymous with the action, (14:04:26) homunq: exactly. (14:04:31) homunq: two possibilities (14:04:55) homunq: The Project == The Action. The Text = a thing. (14:05:20) bemasc: homunq: have you looked at the Journal mockups? That's what we're referring to here. (14:05:22) homunq: if you have two files, one of which is a project and the other is a text (14:05:44) homunq: I think the project should not pollute the files view (14:05:45) homunq: yes (14:05:53) bemasc: There are two views, one of which shows actions (intances), and the other of which shows objects (files) (14:05:54) homunq: that is exactly what I am referring to. (14:05:54) jwildebo [n=jwildebo@e181078067.adsl.alicedsl.de] entered the room. (14:05:56) eben: homunq: arguable (14:05:59) homunq: want urls? (14:06:00) eben: homunq: consider Record. (14:06:29) eben: You take 10 photos. You get each photo as an object. You get the "roll of film" as an object. The roll of film is the project file. (14:06:46) eben: It seems equally valid to send the whole roll to someone, like an album, as it would be to send one photo. (14:06:49) m_stone: eben: hang on there. (14:07:06) m_stone: the roll of film is more usefully regarded as an "object container", i.e. a set or list of objects. (14:07:33) m_stone: we really want other people to be able to process such containers. (14:07:47) eben: m_stone: sure, in this case it is nothing more. In other cases, the container may have a bunch of other data which talks about how to put together the things it contains. (14:08:03) m_stone: however, there's a lot less value in them building support for parsing records of Record-37's graphical state when it was closed. (14:08:03) bemasc: m_stone: right, and that's why the roll of film is the Project File for this instance (14:08:29) m_stone: for sake of argument, call the latter the ui continuation. (14:08:29) bemasc: m_stone: and that's why I'm suggesting that non-critical state be put in a separate dotfile (14:09:35) eben: m_stone: right, a hidden file, or in metadata....but yes....all state not appropriate for the objects themselves goes elsewhere. (14:09:36) m_stone: http://wiki.laptop.org/go/User:Mstone/Bundle_commentary (14:09:40) m_stone: see the picture at the top (14:09:49) J5 left the room (quit: "Ex-Chat"). (14:09:59) m_stone: and the descriptive paragraph below (14:10:21) m_stone: then, please use the already documented terminology until you demonstrate that this terminology is inadequate (14:10:42) m_stone: (though please comment inline in this page and sign your comment if you think I left out something important) (14:11:15) homunq: OK, sorry, I need to go back for a second. (14:11:57) jwildebo left the room (quit: "Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC."). (14:12:00) homunq: I agree with the decision of this conversation that there is no UI-necessary information in version history, that is not in "what actions can I open" (14:12:10) eben: m_stone: where does metadata/state live in this diagram? As "instance"? (14:12:32) homunq: However, I still like version history because it is compatible with the model of forking versions (14:12:43) homunq: of an arbitrary object (14:12:50) homunq: not just of an activity. (14:13:18) m_stone: eben: UI state lives in the "instance" node. (14:13:22) homunq: My feeling is that the journal UI should support this forking-version model in some way. (14:13:24) m_stone: eben: give me some examples of metadata? (14:13:40) eben: m_stone: well, two flavors of it... (14:13:41) m_stone: eben: e.g. who participated, when they did so? (14:13:55) homunq: OK, it was good for me to say that, (14:14:10) eben: m_stone: creation date, participants, tags, description, activity specified metadata such as number of pages, etc. (14:14:24) homunq: it made me see that they are separate issues. (14:14:32) m_stone: homunq: good. (14:14:33) eben: m_stone: and then there is state metadata for the purpose of recovering the instance (the UI continuation part) (14:15:52) m_stone: eben: sure. well, I tend to think about the problem relationally because I anticipate objects (and object containers, which might themselves be objects; I'm making no commitment here) being referred to from several of these action graphs (14:16:22) m_stone: eben: so I would say that the action has a set of time periods when you worked on it. (14:16:23) eben: m_stone: right, I think we all agree to that. (14:16:39) m_stone: likewise for the objects. (14:16:40) bemasc: eben: really? I thought we were going for copy-on-write semantics (14:17:08) eben: bemasc: that's also true, in general. Complicated.... (14:17:27) eben: bemasc: but consider a Journal entry which is just an action "you sent file X to your friend Y" (14:17:38) eben: That's an action which references X, but does not copy it. (14:17:41) m_stone: bemasc: well, this is where we come down to my suggestion that "bytestreams are our identities; the problem is to record appropriate relations on bytestreams" (14:17:56) eben: In fact, it's not a write. (14:18:04) bemasc: eben: right. We shouldn't say actions=instances anymore (14:18:15) bemasc: eben: I would argue that that action does not have any instance associated with it (14:18:17) eben: But that doesn't mean that we won't have multiple actions referring to the same object (actually, version thereof) (14:18:29) m_stone: bemasc: depends whether the action is resumable. (14:18:45) m_stone: bemasc: actions which can be resumed have instances associated because instances are the actual material which permits resuming (14:18:52) bemasc: m_stone: right (14:18:56) eben: Right, which is why the graph m_stone pointed two has those three nodes in a little triangle. (14:19:23) eben: and why the bundle (needed for resuming) is a child of the instance. (14:19:41) bemasc: m_stone: and what we have further been proposing is that each instance refer also to some specific object as the Main Object (14:19:52) m_stone: bemasc: however, even though I can't resume the (completed) action of sending (A,B,C) to Z, I still want to be able to snag A, (A, B, C), or Z... (14:20:16) bemasc: m_stone: I think that makes sense, so the action should retain pointers to the appropriate objects (14:20:17) m_stone: bemasc: and, at face value, that sounds nuts. (though perhaps I haven't understood your use case) (14:20:36) m_stone: (or your design) (14:20:44) bemasc: m_stone: the use case is determining which activities are capable of resuming an action (14:20:54) m_stone: resuming an action? (14:21:04) m_stone: or processing an object container? (14:21:12) bemasc: m_stone: I'm speaking from the user's perspective (14:21:18) m_stone: don't. (14:21:24) m_stone: one makes a new action, the other doesn't (14:21:29) eben: resuming the instance (14:21:47) eben: which bundles, apart from those linked to the instance within a given action, could be used instead if desired. (14:21:49) eben: (?) (14:22:01) m_stone: bemasc: apologies, the "don't" was a visceral reaction - a segment of "your statement does not typecheck" (14:22:19) bemasc: m_stone: The problem is, I've just used Record to take 10 pictures (14:22:53) bemasc: I now want to view them in a gallery that understands Record's photoset file format (14:23:13) bemasc: how should we think about this? (14:23:14) m_stone: (perhaps because it's a standard List format used throughout Sugar...) (14:23:32) bemasc: one option is to offer a number of activities that can resume this instance (14:23:36) m_stone: You View the photoset. (14:24:08) m_stone: That requires finding a Viewer (an activity), instantiating it and telling the instance to process the photoset, and recording the action of Viewing (14:24:31) bemasc: m_stone: the broader question is: when do we resume instances, and when do we open files and thereby start new instances? (14:24:39) m_stone: (Recall that Activities are usefully regarded as prototypes of instances) (14:24:39) eben: m_stone: right, so we're talking about how to "find the viewer" (14:25:22) m_stone: bemasc: there are two formulations. I don't yet have a strong preference between them. (14:25:42) bemasc: m_stone: we are trying to come up with a way to make this determination (14:25:56) m_stone: a) Activities can be used to synthesize instances ready to process some objects. It's just part of what Activities are. (14:26:28) m_stone: so we might use this ability to get an instance attached to our roll of photos which we can "sume" for the first time (since we're not really RE-suming it...). (14:26:34) m_stone: ;) (14:26:34) bemasc: m_stone: and one suggestion is that each instance should identify one of its files as the "project file", and any activity that can open this file can be shown in the UI under "Resume with..." (14:27:24) m_stone: the other option is to say that Activities can be performed on objects and that this creates an Action which, just as a quirk of activity implementation, probably has an instance associated with it that can be resumed. (14:28:09) bemasc: m_stone: I don't understand, as usual. Do you mean Activities can be performed on object containers? (14:28:27) m_stone: I mean that I can Paint on a collection of photos. (14:28:34) bemasc: m_stone: no you can't (14:28:38) m_stone: I think that's a plausible, grammatical statement. (14:28:39) bemasc: m_stone: you can Paint on 1 photo (14:29:10) bemasc: Paint has no idea what to do with an object container containing 10 PNG files (14:29:12) m_stone: bemasc: a technical limitation of the version of Paint we've got at the moment. You prefer that I can Gimp a collection of photos? (14:29:34) m_stone: bemasc: but I agree that my original statement did not typecheck. (14:29:54) bemasc: m_stone: you're being way too abstract for me to follow you (14:30:02) m_stone: ah. apologies. (14:30:14) m_stone: eben: have I lost you as well? (14:30:30) eben: m_stone: Only inasmuch as I don't know what point you're driving at with the example. (14:32:09) m_stone: that "resume with" is either nonsensical (because instances resume and do nothing else) or that what "resume with" should mean is "use <___> as a prototype to make a new instance which, when resumed, will be attached to objects <---->" (14:32:23) m_stone: since activities are logically quite similar to prototype instances (14:32:58) m_stone: in that they offer some fixed UI continuations which can be combined with zero or more objects (14:33:19) m_stone: i.e. they tend to have a default "initial UI" that they use when instantiated. (14:33:49) bemasc: m_stone: nobody else here as written a program in a prototype-based language, so please use a different metapho (14:33:59) m_stone: bemasc: never used javascript? (14:34:09) bemasc: m_stone: oh, didn't know that (14:35:07) m_stone: bemasc: here's another small example: http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Objects-Overview (14:35:28) m_stone: (for future reference. :) ) (14:35:48) bemasc: m_stone: "resume this instance with Activity A" literally means "start Activity A and tell it to open this object container" (14:36:05) m_stone: bemasc: that's how it's implemented today. (14:36:21) m_stone: bemasc: why not just make the "instance" an executable program instead? (14:36:31) arjs left the room (quit: Read error: 104 (Connection reset by peer)). (14:37:01) bemasc: m_stone: that doesn't mean anything. Anything can be called "executable". (14:37:05) m_stone: (actually, I've got an answer for you, but it's a matter of rainbow implementation details) (14:37:32) m_stone: woah, I think I misread your statement. (14:37:34) bemasc: I can declare that my PNG files are executable, and I think I can even patch my kernel to handle them as executables (by opening them in the GIMP) (14:37:37) m_stone: resume this "instance" with activity A? (14:37:45) bemasc: m_stone: right (14:38:03) m_stone: According to my grammar, you should mean "resume this instance|". (14:38:11) bemasc: m_stone: I do not support your grammar. (14:38:20) mtd: m_stone: I think I see the continuation analogy (or philosophy), but pretty much in practice you're not describing something much different than what bemasc is. (14:38:33) m_stone: The "with acitivity A" seems nonsensical. Instances are not parametric over activities. (14:38:44) mtd: given the stack = the metadata and the runtime = a new instance of an activity. (14:38:46) bemasc: m_stone: they are if we decide they are. (14:38:59) m_stone: bemasc: why is the resulting UI a good one? (14:39:25) bemasc: m_stone: mostly because we have no distinction between object containers and instances in the UI (14:39:37) eben: m_stone: agreed on the grammar.... (14:39:46) eben: m_stone: we don't have a good solution. (14:39:49) m_stone: eben: that you do not yet support it? (14:39:53) eben: We considered "as activity A" instead... (14:40:15) eben: no, regarding "resume with" being the wrong speech for the intended meaning of the operation. (14:40:25) m_stone: eben: good. (14:40:29) bemasc: m_stone: the question is really "what should resume mean from the user's perspective?", and I think the answer is "I want to keep working on this abstract project" (14:40:54) bemasc: where the abstract project is concretely represented by an object container, not by any particular activity. (14:41:16) m_stone: bemasc: totally agreed. however, "project" should concretely mean "crazy UI data that I never expect anyone else to deal with" rather than "useful group of objects which lots of other things can deal with" (14:41:32) m_stone: (our comments interleaved poorly there) (14:41:46) m_stone: My comment referred to your 14:40 statement, not the 14:41 statement. (14:41:58) bemasc: so this is the crux of the matter (14:42:07) m_stone: well, of _this_ matter. :) (14:42:08) eben: Actually, project in his meaning was "the file which describes what to do with the useful group of objects" (14:42:20) m_stone: eben: "his" ---> ??? (14:42:28) bemasc: I think a use case is in order (14:42:56) m_stone: bemasc: I wrote one on my bundle commentary page. (14:43:01) eben: m_stone: his == bemasc, the comment you had contention with (14:43:04) bemasc: I write a webpage using the Dreamweaver activity. It's a collection of files, with one HTML file but also CSS and jpeg's (14:43:14) m_stone: bemasc: a simple collection of objects does not innately specify an activity I can use for processing those files. (14:43:15) bemasc: then I decide that I want to view it in the Browser (14:43:34) bemasc: then I decide that I want to edit the CSS by hand in a text editor (14:43:34) m_stone: on the other hand, an instance is navigable to the activity that is its prototype. (14:43:41) bemasc: then I decide I want to open it with dreamweaver again (14:43:44) eben: m_stone: That's the point of the "project file" in the first place. There *is* something that takes on that role. (14:43:55) m_stone: that way, if I want to have another instance of recording on "fish" instead of "butterflies", I can get there from the instance. (14:44:04) m_stone: I can get there from the action of recording butterflies. (14:44:08) eben: And which advertises it's mime-type so other activities can be instantiated from the objects. (14:44:35) m_stone: but I'm not connected solely to Record from the collection of objects. (14:45:12) m_stone: In fact, if record has no photoediting capabilities, I'm might not ever find it adjacent to the photos in the UI. (14:45:54) m_stone: eben: your last comment did not parse. (14:46:27) m_stone: bemasc: what's your question? (14:47:12) bemasc: m_stone: first: how do I open the webpage with Browse? (14:47:21) eben: m_stone: each instance has "a collection of objects" associated with it. one of those is flagged as "the primary object", such that other activities can be instantiated with it as necessary. The primary object knows what to do with "the collection of files" (14:47:22) m_stone: bemasc: you've got tree-structured data. All of our "object containers" to date can be represented as plain old directories. (14:47:41) bemasc: m_stone: right, but how does the Journal know that Browse can open this object container? (14:47:41) eben: m_stone: I don't think that's true. (14:48:14) eben: m_stone: the photos example is a case where the container is empty apart from its contents.... (14:48:34) m_stone: eben, bemasc: I suggest you draw some labelled graphs of the progression of data through your use case. (14:48:46) m_stone: it will be much easier to discuss specific diagrams. (14:48:59) bemasc: m_stone: I am much more interested in working from the user's perspective (14:49:15) m_stone: bemasc: then draw your diagrams from the user's perspective first. (14:49:22) bemasc: what should a user have to do, after having put together a webpage in a creation activity, to view it in the Browse activity? (14:49:22) eben: m_stone: but an HTML instance might have several images, a few sounds, and a video in its object collection, with a HTML file treated as the "object container", including the necessary code to put it all together. (14:49:30) m_stone: bemasc: and translate beneath them into the dataflow perspective. (14:50:22) m_stone: bemasc: begin the action of Browsing the Web-page. (14:50:44) bemasc: m_stone: right. So which button would that be? (14:50:47) eben: you can open the HTML file in the Dreamweaver activity again if you want. You can open it with Browse which will know how to display it. You could open it with SimpleWrite, which would ignore the other objects and just show you the source code. (14:51:12) bemasc: eben: but the HTML file alone will not open correctly in Browse, and this is my key point (14:51:40) m_stone: bemasc: I'm sorry, but text in IRC is not cutting it for me. I'm just not understanding what you're getting at. (14:52:00) m_stone: bemasc: please provide a diagram, or adapt my diagram and show where the fault occurs. (14:52:14) bemasc: m_stone: I cannot diagram this (14:52:35) m_stone: bemasc: can you write a paragraph instead? (14:52:36) eben: bemasc: why wouldn't it open in Browse? (14:52:45) bemasc: eben: because the HTML file is missing the CSS and pictures (14:53:00) bemasc: eben: so it might open, but it would be missing lots of pieces (14:53:11) eben: bemasc: no, all that stuff is contained in the "useful objects collection" of the instance, right? (14:53:12) bemasc: eben: Browse needs to be able to open the whole "object container" (14:53:22) eben: Why shouldn't browse be able to reference thse? (14:54:21) bemasc: eben: because HTML refers to images by paths, but those pictures won't even be visible in the filesystem to Browse (14:54:24) eben: If I have an HTML file and an image on my Desktop, the former referencing the latter, and I open that HTML file, it will work fine. What's the difference here? (14:54:51) eben: Why not? If not, how are they even accessible to Dreamweaver when you resume it!? (14:54:51) bemasc: eben: the difference is that in this case, that image won't even be in the filesystem as seen from the perspective of Browse (14:55:17) bemasc: eben: activities can only see the specific files that they have been told to open (14:55:24) eben: That's the whole point, here, right? Store the objects out individually so other things can use them, but keep the references so that things work with respect to instances. (14:55:42) bemasc: eben: you can't modify the HTML file to include references, or it won't be HTML (14:55:50) bemasc: so instead, we create a "container" (14:56:08) bemasc: I imagine it as a .tar file containing the HTML file, the pictures, and the CSS (14:56:11) eben: :-/ Then what good is this? (14:56:18) bemasc: if you open the .tar file with Browse, it works (14:56:24) bemasc: because it has all the components (14:56:31) bemasc: if you open just the HTML file, you get just the HTML file (14:56:37) eben: bemasc: But the tar file doesn't have type HTML (14:56:52) bemasc: eben: but it does, because we designate the HTML file as the "project file" for this container (14:57:15) eben: No, if that were the project file, then that's what would open with Browse. (14:57:17) bemasc: Browse advertises the ability to read HTML, and this .tar file is listed in the datastore as containing a project file of type HTML (14:57:34) bemasc: so the Journal offers the user the ability to open this .tar file with Browse (14:57:48) eben: bemasc: So you're proposing that every "collection of objects" is a tar file instead. (14:57:49) bemasc: when the user accepts, the datastore unpacks the tarfile into Browse's directory (14:58:04) bemasc: and then points it at the project file, which is HTML (14:58:13) bemasc: eben: not specifically; there are many other implementations (14:58:29) eben: bemasc: OK...but you're talking the technical side. The user doesn't know this was ever tarred. (14:58:32) bemasc: eben: right (14:58:36) eben: They can still see each, and interact with each object. (14:58:38) m_stone: eben: he's just saying it to give your mind the flavor of the packaging-of-related-stuff-together (14:59:01) bemasc: eben: right, but interacting with the HTML file itself is very different from interacting with the whole collection of files (14:59:37) eben: indeed! (14:59:46) cafl left the room (quit: Remote closed the connection). (15:00:23) m_stone: bemasc: the Browse-displaying-website example is really the "interact with this html file in the context of this larger collection of stuff" (15:00:27) eben: but, this poses some problems for the UI.... (15:00:32) bemasc: m_stone: right. Context is key (15:00:38) eben: Consider a Journal entry for this instance...this HTML instance. (15:01:12) eben: It might read: "Today you created This_HTML_File, which contains Image_1 and Image_2" (15:01:18) m_stone: bemasc: so I agree that Browse can use some hints. But I think that Browse _has_ to be able to deal with non-hinted material because it's certainly going to encounter it both because of design changes and because of dumb media like USB keys (15:01:42) m_stone: bemasc: I tend to think of the hint as an xattr, keyed by mime type, attached to the top-level dir representing the container of stuff. (15:01:44) eben: Now, the way to resume this directly is to click on This_HTML_File. (15:01:56) m_stone: bemasc: i.e. it says "dear people looking for HTML - start looking here" (15:02:15) m_stone: "love, the Dreamweaver activity" (15:02:34) eben: One would expect clicking that to resume the instance....not open it independent of the images. (15:02:58) bemasc: eben: I'm looking at your Designs/Journal (15:03:01) eben: What, then, if I hover and wait for the palette to appear, to do "resume as" (or whatever we call it)? (15:03:21) m_stone: eben: "act on with" (15:03:24) bemasc: eben: It has two views: action view and object view (15:03:39) bemasc: eben: the action in question shows 4 files (15:03:46) eben: ok (15:03:52) bemasc: if you choose to resume the action with Browse, you get all 4 files (15:04:01) bemasc: and the webpage consists of a combination of all 4 files (15:04:06) m_stone: bemasc: ARGH. be grammatical. (15:04:10) m_stone: bemasc: :) (15:04:33) m_stone: bemasc: if you choose to act on all four files with Browse, you want to get a webpage full of pictures and CSS. (15:04:36) bemasc: yes (15:04:56) bemasc: alternatively, if you choose to act on just the HTML file with Browse, you'll get just the text, no formatting or pictures (15:05:13) bemasc: or if you choose to act on just the picture with Browse, you'll get just the picture (15:05:21) eben: bemasc: back up a step. "choose to resume with Browse"... (15:05:24) eben: How do you do that? (15:05:32) bemasc: and you can't open just-the-css with Browse, because it doesn't support that type (15:06:07) m_stone: eben: I "asked" the same thing. I suggested that bemasc really meant "when you decide to act on all four files with Browse" (15:06:12) bemasc: eben: I'm actually not sure, because I don't see any way to resume an action in Designs/Journal (15:06:27) eben: My point here is, looking at the mockup, "Rain Forest" is the "roll of film", and it is likewise the Project File (15:07:14) bemasc: in other words, the project file is hidden (15:07:33) eben: bemasc: Well, right. The main point to recognize there is that the instances are represented as the activity icons. The objects are thumbnails (or a similar treatment, as seen in object view, which contains the activity icon on a "page") (15:07:35) m_stone: eben: my suggestion is that you pull the representation of the object container (holding the four objects) [sic: dir holding four files] onto the Browse activity. Or you select Browse from the list of activities to act on this data with, (where we suggest it either because of an explicit hint or because we suggest all activities which can process any file contained in the group) (15:07:39) bemasc: or one of the pictures is designated as the project file (15:07:56) eben: bemasc: The intent was to make resuming an instance as simple as clicking on the primary file which represents it. (15:08:01) m_stone: bemasc: that's a really bad design. (15:08:05) m_stone: bemasc: you're going to want more than one of them. (15:08:27) eben: Of course, each object (including the primary file) has a little "details" button next to it, which takes one to the detail for the object (independent of any instance at all) for acting directly on the object itself. (15:08:34) bemasc: m_stone: I don't know what you're referring to. I'm just attempting to figure out what's going on in slide 2 (15:08:50) m_stone: bemasc: I'm saying that the idea of "a single designated Primary Object" is folly. (15:09:02) bemasc: m_stone: it's necessary (15:09:09) m_stone: bemasc: for two reasons. (15:09:29) m_stone: bemasc: one because you're going to want more than one of them. and two, because you can't guarantee that it will exist in the presence of dumb media. (15:10:00) eben: m_stone: in dumb media, every "instance" is associated with one and only one object. (15:10:04) m_stone: so, in my opinion, you have no choice but to design a UI which does not depend on their existence in order to function. (you should, however, design a UI which takes hints that it can find) (15:10:15) eben: What does it mean to want more than one? Doesn't that just imply you have two instances? (15:10:23) m_stone: eben: take the web-page example. (15:10:38) m_stone: eben: it has some html, some css, and some photos. (15:10:56) m_stone: maybe you're lucky enough to have AwesomeEditor [etoys?] that handles all three. (15:11:16) m_stone: eben: however, in practice, you're likely to want to mix and match. (15:11:19) m_stone: right? (15:11:56) eben: m_stone: mix and match in what sense? One could "open" any of the objects independently. (15:12:11) m_stone: eben: but some of them must be opened in context in order to make sense. (15:12:45) m_stone: I can probably cook up an example that obviously has two different kinds of objects which need to be opened in context to make sense, but let's go with this one for the moment. (15:13:07) bemasc: the abstract "Webpage" consists of all 4 files. If you want to start an activity instance to view the webpage, that single instances needs to have access to all 4 objects. (15:13:14) m_stone: eben: an essay containing labelled diagrams is an easy example. (15:13:32) eben: in what context? Either I care to look at the collection as a whole, for instance, in Dreamweaver, or I care to look at a single object from the collection. (15:13:35) bemasc: so one object = one instance won't work (15:13:45) bemasc: eben: I agree. (15:13:56) bemasc: eben: the problem is, the UI has no way to open a collection (that I know of) (15:14:17) eben: bemasc: But you just got through proposing the tar approach for getting around that internally (15:14:19) bemasc: eben: the only way one ever opens a collection, in the mockups, is to "resume" an activity (15:14:27) bemasc: eben: sure, but I'm talking about in the UI (15:14:48) eben: Ah, yes. (15:14:50) bemasc: the hard part here is design, not implementation (15:15:02) bemasc: (we have hard implementation problems elsewhere) (15:15:08) m_stone: :) (15:15:11) eben: The only way to *use* the collection of objects is to do so from its corresponding action entry, naturally. (15:15:17) bemasc: right (15:15:20) m_stone: eben: how do you mean? (15:15:43) m_stone: eben: consider turning a roll of photos into a slideshow (15:15:53) eben: In these designs, the implicit assumption was that the "primary object" served as a standin for the instance itself, which when clicked on resumes the instance. (15:16:08) bemasc: you mean a stand-in _in the UI_ (15:16:12) bemasc: I hadn't thought of that (15:16:32) eben: In the same manner, that object would be the thing which had a "resume this instance as activity X" option in its palette (15:17:21) bemasc: eben: but every object can be opened by other activities (15:17:26) eben: In other words, the representation of the primary object in the design is *as* the instance... (15:17:35) bemasc: so one object can be opened or resumed, and these mean different things? (15:17:37) eben: bemasc: Right, so there's a hole in the system, right? (15:18:05) m_stone: eben: well, how does the photoroll -> slideshow example work? (15:18:16) eben: You can act on that thing either as the instance, or as the object. So maybe that's busted. Maybe we need to in fact represent it "twice" in the UI. (15:18:52) m_stone: eben: furthermore, suppose I resume the action of photographing butterflies. Presumably, the next time I edit my slideshow, I'd like to be reminded that there are new butterfly photos. (15:19:01) eben: Maybe, for instance, that slide should also have a "Rain Forest" *object* down below, with a preview...(a contact sheet, let's say, with the 4 images on it) (15:19:57) bemasc: eben: what I want is a way for the user to open a collection (15:20:25) bemasc: eben: Currently, collections are only represented, as actions, so I've been using the word "resume" to refer to opening a collection (15:20:40) m_stone: (and, in future work, pay attention to changes made to that collection [or to new versions of it that appear, etc, etc) (15:20:50) eben: currently, meaning in the designs we're looking at, right? (15:20:55) bemasc: eben: yes (15:21:41) eben: Right, as an aside, another missing component of the current design (a big one) is that there is no way to say "show my all versions of this instance" (15:21:54) eben: The current design only really has versioning for objects, not instances. (15:22:07) m_stone: eben: at the big Journal meeting w/ marco, tomeu, bertf, &co. we definitely discussed being able to use collections as part of several actions. (15:22:22) m_stone: eben: not "collections", you mean? (15:22:43) m_stone: eben: :) (15:23:24) eben: Ummm, I don't know? (15:23:32) m_stone: fair enough. :) (15:23:35) bemasc: it depends on what the metaphor is (15:23:49) eben: I mean, if I resume an instance 5 times, make changes each time, and then want to see the chain of actions I took to get to where I am. (15:26:00) bemasc: and let's not forget the problem of figuring out which version of an activity can resume an instance, which is how this conversation started (15:27:26) eben: I feel like we've gotten about nowhere in an hour. (15:27:29) m_stone: bemasc: (a problem with at least one easy solution, namely, to regard instances as executables derived from some prototype...) (15:27:35) m_stone: eben: you're wrong. :) (15:28:02) eben: Perhaps we need to have an in Cambridge meeting to resolve all of this, going through the posted Journal designs and hammering it until we have a solution for all these issues. (15:28:10) eben: m_stone: I'm glad I'm wrong! (15:28:19) m_stone: eben: we had a nice synchronization of terminology. we know of a use case - record butterflies, make slide show, record more butterflies, update slide show - that it's not quite clear how the present design would represent. (15:28:36) bemasc: (I thought you guys already _had_ this meeting, 7 months ago) (15:28:44) m_stone: we also have the make website - view website - edit images - edit html - view website sequence. (15:29:37) m_stone: and the thoughts derived from consideration of that use-case, namely, that our UI will work much better if we attach some hints to collections but that we cannot rely on the existence of these hints. (15:29:48) eben: bemasc: We did. It resulted in the mockups you see. Which still aren't perfect! (15:30:08) m_stone: eben: they don't need to be perfect. they've already allowed significant progress (15:30:18) m_stone: eben: they're mockups for a reason! :) (15:30:24) eben: m_stone: right, both of those use cases are not covered, at present, by the design. (15:30:42) eben: Mostly because we don't have aliases/references in that sense at all. (15:30:50) m_stone: eben: so we should explain that clearly on the design and send some email so the rest of the world can think about it. (15:31:00) eben: m_stone: certainly, that's my point, and why I think it's worth another meeting to make them better. (15:31:06) m_stone: probably with a cleaned-up summary of this conversation like the previous ones I've written. (15:31:47) m_stone: eben: could be, so long as we record it and summarize it the same way. (15:32:38) m_stone: eben: did I convince you that you were wrong? (15:32:51) m_stone: (about the claim that the last hour was wasted) (15:33:41) eben: m_stone: Oh, I didn't say "wasted". I said that we hadn't gotten far (really, raised more questions than answered). Yes, I think it was productive nonetheless. (15:34:12) m_stone: ah. I misread you. (15:34:42) m_stone: "about nowhere" is very evocative. (15:34:54) eben: As an interesting option, by the way, we could consider making the way you act on an object contextual to where you initiate the action from. For instance, if I "open" an image in an HTML instance from that instance, maybe it actually saves "in place" by just creating a new version of that instance, with the appropriate file changed? (15:35:34) eben: Whereas "opening" the object from within object view would treat it wholly independently, and use the copy-on-write approach to create a new instance for the changes. (15:35:47) m_stone: eben: I didn't quite follow that comment and I need to relocate to 1cc anyway. (15:36:01) bemasc: eben: I think I get it. Interesting... (15:36:13) m_stone: eben: sounds like it's worthing reflecting on though. (15:36:52) m_stone: if I undertake to summarize this discussion, it will probably take me until the weekend. (15:37:02) bemasc: eben: it sounds like it might be easy to break things though. For example, a Desktop Publishing application might record the dimensions of all its images, and fail to load them properly if the dimensions change unexpectedly (15:37:21) HoboPrimate: can't the use case of creating a new instance of an object be taken care by copy+paste and/or "Keep as New" within the activity? (15:37:29) m_stone: do you want me to do it or does one of you fine gentlemen prefer to take the honor? (15:39:01) ***bemasc is trying to get other things done today, but ... maybe (15:39:53) eben: m_stone: I don't think I'd get to it any sooner than you. Also, from past experience, I trust your ability to accurately summarize and categorize the meaningful bits better than I could. (15:40:30) m_stone: very well.(12:39:37) homunq: eben - I want to start coding new activity bundle format, do you have a minute to talk about your UI vision there? (12:39:55) eben: homunq: Sure, let's do it. (12:40:31) homunq: I think the main question is, is it worth including enough info to reconstruct "broken threads" (12:40:49) homunq: with forks being one case of the latter. (12:41:18) homunq: The UI I envision that becomes possible when you do (12:41:45) eben: homunq: Well, I still haven't been convinced that broken threads should in fact be reconstructed. I personally feel that a broken thread should be treated as a separate activity. (12:41:59) homunq: is that when a "newer" activity becomes available that crosses a break (12:42:27) homunq: the user has some easy way to explicitly update favorite version (12:42:36) homunq: and explicitly update instances. (12:43:07) homunq: newer version update implicitly within an unbroken thread (12:43:28) homunq: and you can explicitly say "use original version" if it is available (12:43:57) homunq: with aggressive backups of activity versions, so that if you have server coverage chances are you can get orig version. (12:44:24) eben: where the "original version" could be an activity on the other side of a break? (12:44:51) homunq: The principal reason I think that broken threads are worth it, is that it makes our security model more in-line with reality. (12:44:55) homunq: and thus more secure. (12:45:04) homunq: because people will not be subverting it. (12:46:03) homunq: original version could not be on other side of a break because the only way to cross a break is to open (12:46:12) homunq: and opening saves a new version of the instance (12:46:25) eben: But I disagree with it on the principle of allowing "just anyone" to create new activites based on existing activities which appear as "new versions" to the rest of the kids. (12:46:31) homunq: so only the old instance would have an old original version. (12:47:00) eben: OK. So consider activity A. (12:47:22) homunq: OK. exists in version Ax.1 (12:47:26) homunq: Ax.2 (12:47:30) homunq: Ay.3 (12:47:47) eben: right, perfect. (12:48:33) homunq: so you have an instance of Ax.1 (12:48:39) homunq: and then you get Ax.2 (12:48:49) homunq: instance automatically opens using Ax.2 (12:48:55) homunq: Now you get Ay.3 (12:49:03) eben: now, Bob comes along, guts A and derives Ay.1 (12:49:32) homunq: No... the rules would be that version number keeps increasing. (12:49:49) homunq: something derived from Ax.1 is Ay.2 (12:49:59) homunq: Or in our example Az.2 (12:50:03) homunq: because y is taken. (12:50:03) eben: homunq: But this is the point we disagree on. You say that it increases, because the "identity" doesn't change. (12:50:14) eben: I say that it starts at one, because it's effectively a new activity. (12:50:33) homunq: OK. So whose example are we following? (12:50:44) eben: homunq: Well, I'm trying to contrast them. (12:50:44) homunq: I say mine, because the burden of proof is on me. (12:50:52) eben: OK. (12:51:08) homunq: OK. So you get Ay.3 (12:51:33) homunq: now if you just run your instance, it still runs as Ax.2 (12:51:44) eben: Ax.1, Ax.2, Ay.3 (that's it so far, yes?) (12:51:57) homunq: but it has an extra button in the journal "update me" (12:51:59) homunq: yes (12:52:18) eben: OK. In other words, Ay.3 did not get auto-favorited, even if Ax.2 was already favorited. (12:52:35) homunq: and the palette or something on that button says "Ay.3 claims to be a newer version, but I cannot be sure" (12:52:59) homunq: or something of the sort - conveys the alleged nature of the relationship. (12:53:17) homunq: Exactly. (12:53:47) eben: OK. Is there a need for this button? Couldn't the kid just manually choose to open the instance with Ay.3 if they choose? (12:53:50) homunq: Favoriting and instances are two different (but related cases), I'm talking instances right now. (12:53:52) homunq: but yes. (12:54:24) homunq: Yes, they could do it manually, (12:54:34) homunq: but I think it is nice to have the button. (12:55:07) eben: And why do you think it's safe to tell the kid that this is a "new version"? (12:55:26) homunq: I think it is safe to say "claims to be a new version" (12:55:32) homunq: Note: (12:55:35) eben: How does it claim this? (12:55:44) homunq: implementation detail (12:55:47) eben: It retains the same service name, I guess? (12:55:52) homunq: no (12:55:58) eben: It has a new service name? (12:56:03) homunq: service name is not user-readable (12:56:15) homunq: it can have same or different user-readable name (12:56:17) eben: who cares if it's exposed. (12:56:34) eben: In your model, does Ay.3 have the same service name as Ax.2? (12:56:39) homunq: but it has a list of previous service ID's and version-of-fork (12:56:48) homunq: service name? (12:56:55) homunq: do you mean org.laptop.xxx (12:57:01) eben: homunq: Each activity bundle has a unique identifier. (12:57:01) homunq: or user-visible name? (12:57:02) eben: Yeah. (12:57:07) homunq: which? (12:57:19) eben: The unique bit, which registers it as what it is. (12:57:27) homunq: not same. (12:57:40) homunq: same in unbroken thread, changes in broken one. (12:58:23) homunq: unique is thus just hash, though (service ID, version) comes close. (12:58:36) eben: OK. So this is my point of contention. How is it proper to suggest to the kid that something with a) a new author and b) a new service name is a "new version" of something they already have? (12:59:03) homunq: OK. there is another bit I have to explain. (12:59:14) marcopg [n=marco@host145-118-dynamic.9-87-r.retail.telecomitalia.it] entered the room. (12:59:16) homunq: In my model, there are private instances. (12:59:26) eben: For that matter, how is it fair to the author of Ax.2 if anyone out there can come along and push (via suggestion) a "new version" out there which may be totally different, or buggy, or corrupt? (13:00:09) homunq: Any instance marked private cannot be opened by an activity which has P_NETWORK unless it has the same service ID as creator. (13:00:10) eben: I think that activity thread deserves to have a sense of ownership associated with it. (13:00:38) eben: Any instance that has not been shared? (13:00:45) homunq: I think that it is perfectly fair, if you give users explicit choice (13:00:51) homunq: and default is Ax.2 (13:01:06) eben: sorry, what's fair? (13:01:32) homunq: how is it fair to the author of Ax.2 if anyone out there can come along and push (13:01:34) eben: Oh, suggesting that Ay.3 is a new version of Ax.2? (13:01:38) homunq: yes (13:01:47) eben: No, I don't think that's fair at all. (13:02:08) homunq: I think that people sometimes want to assert that (13:02:17) homunq: and sometimes have good reasons for wanting (13:02:28) eben: I think you might get away with saying "Here's something (Ay.?) that claims to be an *alternate* version of the Ax.2 you have been using" (13:02:35) homunq: without having good reasons for getting the x signing key. (13:02:42) homunq: OK. (13:02:45) homunq: Alternate. (13:02:50) eben: Saying that something is a new version implies a chain of trust to me, and an authorship, which doesn't apply in this case. (13:02:55) homunq: that is good language. (13:02:57) eben: That's a really big difference. (13:03:26) homunq: Fine. (13:03:38) eben: To me, and it's why I personally like calling it Ay.1 (The first version of an alternate thread), even if it was based upon something else. (13:04:50) homunq: OK, but then what about Az.1 which inherits from Ay.1? How does it say that Ay.1 is a later ancestor than Ax.2? (13:05:15) homunq: That is what the monotonic versions are for. (13:05:31) bemasc: homunq: the key thing here, I think, is that eben is also proposing that instances be explicitly mime-typed (13:05:54) marcopg left the room (quit: "Ex-Chat"). (13:06:11) homunq: But is there any support for format versioning in mime types? (13:06:30) eben: homunq: I'm not sure....do we need full ancestry? (13:06:46) eben: (across threads, that is) (13:06:51) bemasc: homunq: so the type of an instance created by "Ay.2" is not "Ay.2". The type of that instance is "xml/tamtam-projectfile" (13:07:12) bemasc: homunq: if you change the format in an incompatible way, then you should introduce a new "mime type" to describe the new format (13:07:27) homunq: define "incompatible" (13:07:28) eben: If one thread simply uses monotonic versions and full ancestry internally, and perhaps also includes the thread it forked from, do we really have need for more? (13:07:31) bemasc: (possibly not actually "mime" format, but some kind of project file with type) (13:07:33) homunq: that is the problem for me. (13:07:42) homunq: if you add a new bit of data (13:08:05) bemasc: homunq: if it breaks the spec for that filetype, it's a new filetype (13:08:08) homunq: that does not break the old activity, but is not supported by it, how is that indicated in mime-type-land. (13:08:15) eben: homunq: incompatibility certainly comes as a responsibility, in my mind, of the author of the thread. (13:08:38) bemasc: homunq: that's the author's decision (13:08:41) homunq: but I think that most format changes are in the grey area of compatibility. (13:08:48) bemasc: homunq: that's why it's the author's decision (13:08:55) eben: homunq: Consider, for instance, taking Ax.2 (because you love the interface) and on purpose explicitly swapping out all of the data formats/protocols used for your own. (13:09:17) homunq: but it is a decision of whether it is totally different or totally the same, when the reality is neither. (13:09:39) eben: This is a case where, clearly, each thread can stand alone, but there is no intent to make the two threads compatible with each other...and why should there be? The are authored by two separate people who may not even know each other. (13:09:53) homunq: In that case, your new activity is not a child version (13:10:01) eben: homunq: But that decision can only be intelligently made when you restrict the scope to a single thread. (13:10:03) homunq: exactly, stand alone. (13:10:43) homunq: sorry - we are talking about two things. mime type and activity ancestry. (13:11:03) homunq: I do not want ancestry to be an archeological record of code origin (13:11:04) bemasc: homunq: ancestry does not imply compatibility. Witness MS Word. (13:11:50) homunq: if you change file formats incompatibly, you start a "new activity" (13:11:51) bemasc: homunq: and conversely, witness AbiWord, which is by no means descended from MS Word, but (relatively recently) got .doc import capability (13:11:58) homunq: even if it has same user-readable name. (13:12:18) bemasc: homunq: the question is: what can ancestry tell us? (13:12:30) bemasc: or rather, what actions can the system take on the basis of ancestry (13:12:59) bemasc: you're proposing one action the system can take on the basis of ancestry: determining which Activities are capable of opening which files (13:13:22) homunq: yes (13:13:31) homunq: and giving it as option for user (13:13:54) bemasc: another action the system can take is inheriting permissions. After some discussion at the "mini-conference", there was some consensus that if a future version of Activity is signed by the same key, then it should inherit the user's permission settings for that activity (13:14:03) homunq: not just using the ordinary "open with" but somehow giving that option more prominence. (13:14:17) homunq: agreed (13:14:24) eben: bemasc: yes, good point. (13:14:39) homunq: and signature-breakages do not. (13:14:42) homunq: obviously. (13:15:12) bemasc: homunq: so far, I still prefer explicitly typed instance formats (13:15:33) homunq: explicitly typed, but not versioned? (13:15:33) bemasc: and if you've broken compatibility with the previous versions, you should declare a new instance format (or increment your version format number) (13:16:03) homunq: mime types have a version number? (13:16:04) bemasc: homunq: versioned entirely separately from the activity bundle itself, and possibly with no assumption of backwards compatibility (13:16:14) bemasc: homunq: you can just add a number on the end, if you want (13:16:25) eben: OK....so activities that break signature, you agree, have new service names, do not automatically receive the same permissions, what else? I still fail to see an argument for treating it as a "new version" in the same thread. It's effectively a new animal. (13:17:04) bemasc: eben: homunq wants to use a non-secured ancestry system to determine instance compatibility (13:17:19) homunq: yes (13:17:33) bemasc: this amounts to declaring that the type of an instance is the specific version of the activity that created it (13:17:47) homunq: I also want it because I think that if we do not provide an un-secured (and thus un-trusted) mechanism (13:18:07) bemasc: and then another activity can declare "I can open that instance" by listing that activity version as one of its ancestors (13:18:08) eben: Wait wait....I find your last comment disagreeable, bemasc (13:18:09) homunq: I think that developers will feel undue pressure to use the trusted mechanism in inappropriate ways. (13:18:28) bemasc: eben: please explain (13:18:48) eben: If the type of an instance is 1-1 with its (activity,version) pair, then we don't have any kind of cross activity compatibility.... (13:18:57) homunq: bemasc is giving an accurate characterization of my position (13:19:35) homunq: for instances, no (13:19:40) homunq: just for files (13:19:51) bemasc: eben: in homunq's proposal, Activity B.8 can only read something written by A.3 if B.8 lists A.3 or later as an ancestor (13:20:04) homunq: instances (13:20:05) homunq: not files halish HoboPrimate homunq (13:20:10) bemasc: homunq: yes (13:20:22) homunq: that is my proposal. (13:20:29) bemasc: homunq: conversely, in eben's proposal, instances are handled just like files, in terms of typing (13:20:33) eben: that seems arbitrarily limiting, no? (13:20:58) homunq: note that multiple inheritance is possible. (13:21:00) bemasc: so A.10 can declare that it only reads a certain instance types, and the type written by A.3 might not be in that list (13:21:04) eben: What if these activities have no idea each other exists, but they share a common format? (13:21:14) bemasc: so then activity A.10 might not be able to open instances of A.3 (13:21:22) eben: They should "just work", and the system should know that they can handle each other's formats. (13:21:32) bemasc: eben: I agree, which is why I prefer your proposal (13:22:06) homunq: Sorry, one more detail. (13:22:07) bemasc: also, it could be that A.10 is a direct descendant of A.3, signed with the same key, so it should inherit permissions, even though format compatibility has since been broken (13:22:39) homunq: Ay.10 can say "I save in format Ax.3" (13:22:51) eben: it seems absurdly silly that a simple activity that writes a text file shouldn't result in something that can be opened by any other text editor created in the past or future. (13:23:07) bemasc: homunq: also, your system can be implemented easily inside eben's (13:23:07) homunq: eben: of course (13:23:18) homunq: that is why I keep saying "instances not files" (13:23:25) homunq: the text file can be opened (13:23:27) homunq: sorry (13:23:29) homunq: actions (13:23:39) homunq: actions = instances (13:24:36) homunq: but "I emacsed that" and "I wrote that" are not compatible. (13:25:01) bemasc: homunq: if you want, your Ax.3 can call its instance save format "Ax.3", and your Ay.5 can list "Ax.3" among the instance types it can resume (13:25:41) eben: homunq: Instances with all associated metadata and goodies? (13:26:01) homunq: eben: essentially, yes. (13:26:36) eben: Actually, I guess we haven't ever had the notion of an "instance type" to be honest.... (13:26:51) bemasc: eben: that's because we haven't had a distinction between files and instances (13:27:10) homunq: eben: not in reality, but in your new journal spec with actions it's pretty clear. (13:27:18) eben: Thinking about it, the whole idea was to treat the instance as having the type of the "primary file" object, such that one could say "open with X" and it would simply open that file in the new activity. (13:27:20) bemasc: eben: you specifically said that you imagined a scenario in which each instance was associated with a "project file" (13:27:54) eben: bemasc: Yes. I think each instance will have a "project file", and that project file will have a type. (13:28:06) eben: But in my head that type was TXT or PDF or PNG or HTML.... (13:28:13) homunq: eben: that makes no sense to me. An action can have multiple, incompatible files associated. (13:28:35) bemasc: eben: right, but TamTamEdit's project files are going to be some complicated custom format (13:28:38) eben: homunq: But it has to have a file which encapsulates those as a project. (13:28:49) homunq: Also, in my head, the instances/actions had some of their format in metadata (13:29:07) homunq: or is that abusing metadata? (13:29:13) eben: OK, let's try to tease this apart.... (13:29:28) bemasc: I think metadata should only be things that the user is invited to mess with (13:29:46) homunq: bemasc: OK granted. (13:29:54) homunq: screenshot? (13:30:01) homunq: not metadata then. (13:30:07) bemasc: homunq: changing the screenshot won't screw up the instance (13:30:33) eben: Sure, that's fair....metadata was to hold the state data which does not fit into the "well known file format" assuming there is one, or which the author doesn't feel is a necessary part of their new file format if it's not a known one already. (13:30:37) homunq: could be a security hole, and can't think of a positive use case. (13:31:29) bemasc: my rule of thumb would be, "the user should be able to write and delete metadata arbitrarily and at random without screwing up the instance when it resumes" (13:31:48) homunq: bemasc: that is a fair rule. (13:32:07) homunq: thus we need some other concept of quasi-metadata (13:32:10) homunq: for screenshot (13:32:12) eben: So, in my head at the time, the point of separating the actions from the objects was so that the metadata *could* hold the "extra" stuff, and so that it *would* be possible to say "open this instance with some other activity" because the file associated with that instance would be just a well known format of some kind. (13:32:14) bemasc: homunq: XML (13:32:19) homunq: for private signing key (13:32:25) bemasc: homunq: oh (13:32:27) homunq: OK that is implementation (13:32:40) bemasc: (I misunderstood you, never mind) (13:33:10) bemasc: eben: project files are almost always application-specific (13:33:27) bemasc: eben: the example in my head is Audacity (13:33:27) homunq: eben: I had thought the same as you (13:33:33) eben: bemasc: Umm, I think that's about a 50/50... (13:33:45) homunq: but now that we are being explicit, I like bemasc's rule of thumb better. (13:34:24) homunq: bemasc: I don't know much about audacity, what is the issue there? (13:34:33) eben: bemasc: sure, good example. So yes....in the case of an Audacity instance... (13:34:50) homunq: a project file has different sounds in it? like a concurrent playlist? (13:34:51) bemasc: audacity uses an XML-based project file format to describe the project itself, and also stores bits of audio in another directory that has like 1000 little audio files in it (13:35:00) eben: only audacity (right now) can read that file (even though others could read, for instance, the samples used or the rendered output of it) (13:35:14) homunq: OK. (13:35:19) bemasc: the project file format is specific to audacity, and is occasionally changed in a non-backward-compatible fashion (13:35:19) eben: But, there still is a file, and it still has a format, and other activities could certainly adopt it in the future. (13:35:21) homunq: good example. (13:35:46) homunq: that stuff clearly is not metadata (13:36:02) homunq: despite what eben and I vaguely thought (13:36:04) bemasc: So the question, for me, is UI (13:36:28) eben: It would be prudent for the creator of that format to keep all the necessary data for the project inside it, and to save other info (perhaps UI hints about the selected tab, the current view settings, etc.) as state metadata. (13:36:31) bemasc: If someone writes an Audacity-compatible Activity, what should users do to continue their work in this new program? (13:36:58) homunq: eben: why? (13:37:05) bemasc: Is that an example of resuming your work, or an example of starting a new instance? (13:37:06) homunq: why not keep the tab in that project? (13:37:25) eben: homunq: because that info is specific to the UI of the activity, and the platform that the activity runs on. (13:37:51) eben: I have audacity for OSX. It doesn't have tabs. It probably has a completely different and perhaps incompatible UI. (13:37:51) homunq: OK, so actions have 4 kinds of data (13:37:54) homunq: files (13:37:58) homunq: projects (13:38:03) homunq: view settings (13:38:07) homunq: metadata (tags) (13:38:11) eben: Consider likewise a painting program. Clearly you want the "project file" to be simply an image, for the best portability. (13:38:26) eben: Storing the currently selected color would be metadata. (13:38:36) homunq: I'd rather not assume that any of those are equivalent. (13:39:04) homunq: if an activity author wants to assume that, fine. (13:39:14) eben: (This, too depends....for instace, if an SVG editor decided to support .ai instead of .svg, then the color would be stored too, perhaps, as part of the actual project file....but that's all dependent upon the standards in place, or being set up in the case of new activities.) (13:39:29) homunq: but the model would be, keep 4 separate. (13:39:38) bemasc: eben: undo history (13:40:03) eben: bemasc: another interesting one....that would be part of the state too, right? (13:40:21) bemasc: eben: well, that's the question. An image editor clearly doesn't store the undo history in the image (13:40:29) homunq: in a perfect world, undo history would be in olpcfs ... (13:40:34) bemasc: homunq: I agree. (13:40:38) homunq: I'm actually kinda serious. (13:40:43) eben: homunq: I actually see 3 myself: associated files (of which one is the project), state blob, and metadata. (13:41:05) bemasc: eben: I'd like to work from the UI down (13:41:07) eben: homunq: in practice, the state blob might be some piece of inaccessible metadata. Well, needs to be. (13:41:38) bemasc: eben: As a user, I go to an instance and click "resume" or whatever. What happens? Am I shown a list of activities that can resume this instance? (13:41:39) eben: homunq: Sure, that would be great. But it's definitely not part of the file itself, right? (13:41:42) homunq: "inaccessible" is the point (13:41:53) homunq: this is different in some key way from normal metadata (13:42:01) homunq: the implementation can be the same though. (13:42:35) bemasc: eben: the PSD format stores undo history, I think, and so does gimp's XCF (13:42:43) homunq: bemasc: there is a "just resume" button, you click it, it defaults to something. (13:42:50) eben: bemasc: It resumes with the last activity you used. (13:42:50) homunq: you hover it, it gives you choices. (13:42:56) eben: (for that instance, of course) (13:43:04) bemasc: eben: ok. If there's a new version, does it use the newer version? (13:43:38) eben: bemasc: I would argue yes, if it is part of the same thread. (13:43:42) homunq: (new version AND new version can open that data) (13:43:48) bemasc: homunq: right (13:43:48) homunq: eben: agreed. (13:44:21) eben: Another potential option is to say that it uses the newest starred version, if there is a starred version in the thread, or the most recent otherwise. (13:44:24) bemasc: eben: ok. What if there are no more activities installed in the thread, but there is another activity installed that can resume it? (13:44:25) eben: Again, assuming it can. (13:44:26) homunq: so the data has a master file which gives it its format (13:44:46) eben: bemasc: In that case, we probably (currently) pick the next in the list. (13:45:04) bemasc: eben: what if I want to resume with a non-default activity? (13:45:09) homunq: currently, it is a mess. let's not go by currently. (13:45:11) eben: A better solution would be to present a modal dialog presenting the available options, including the option to attempt to recover the activity which created it. (13:45:37) bemasc: (or a non-default version) (13:45:40) eben: bemasc: If you want to do that you use the secondary palette of the resume button, which lets you choose anything that supports the type. (13:46:05) bemasc: eben: that all sounds pretty reasonable to me (13:46:15) homunq: eben: problem with that: (13:46:24) homunq: if you have 5 versions in the same thread? (13:46:26) eben: bemasc: One option for the non-default version case is to say that the list is actually hierarchical (one level) (13:46:30) homunq: they all clog up that list? (13:46:38) bemasc: eben: makes sense (13:46:51) eben: bemasc: If there are more than one version of an activity available, it could yield a submenu of the options, and indicate which of those are starred as well. (13:47:07) homunq: OK. (13:47:18) eben: homunq: No, the versions that are in an unbroken thread are treated as "one thing" until you ask for more info. (13:47:43) eben: This is the same as what I intended to represent in the activity list in home. They would be grouped by unbroken thread. (13:48:24) eben: But Ax.? and Ay.? would both appear in the top level list, side by side (well, depending on sorting...but assuming they choose to keep the same readable name) (13:49:01) bemasc: It sounds like the system has the following: (13:49:23) bemasc: each instance is a collection of files, one of which is declared the "main file". Each file has an explicit type. (13:49:36) bemasc: Each instance has "application metadata" and "user metadata" (13:50:05) homunq: There is only one issue this does not address... what if format tamtam-project5 can be opened imperfectly by tamtam-project3? (13:50:26) homunq: obviously tamtam3 cannot preemptively say this. (13:50:29) bemasc: the application can use application metadata as a convenience to store a small amount of simple data that is some how "not worth" putting in a file (13:51:05) bemasc: homunq: we could allow files to have multiple types (13:52:08) eben: bemasc: not worth or not appropriate (in the case of trying to adhere to already defined formats) (13:52:22) homunq: Other issue: what if different subfiles have different levels of privacy? (13:52:34) homunq: I am thinking about private signing key for an activity bundle (13:52:41) eben: homunq: hmmm, worst case, TamTam5 includes a way to export a TamTam3 file/instance (13:53:24) bemasc: eben: well, another solution (for a paint program) would be to have the instance contain "image.png" in PNG format and "mysettings.paint" which is a JSON file with activity-specific settings (13:53:29) bemasc: and make image.png the project file (13:53:30) homunq: But if I have an instance, and I have an app I like which opens tamtam3, but I do not have tamtam5 activity. (13:53:30) eben: homunq: That is a *really* tricky question....it's part of the reason that we didn't use aliases at all in the past... (13:53:55) eben: bemasc: instead of the state blob as metadata? (13:54:25) bemasc: eben: right, the "activity metadata" could easily be stored in a file other than the project file, without breaking compatibility (13:54:32) eben: bemasc: I think the goal is to prevent those kinds of "junk" files from accumulating, since the kids can also browse the objects as well. That's not meaningful as a file itself, to the kids. (13:54:46) bemasc: eben: JSON is fairly human-readable (13:54:59) bemasc: we could also adopt a "dotfile" convention like the one used in all UNIX systems (13:55:22) eben: bemasc: Well, sure, but in the interest of making it easy to browse through the objects one has created, seeing ever other one being a settings file would be obnoxious. (13:55:23) bemasc: hiding things from the user is generally bad, but the "activity metadata" would be hidden from the user anyway (13:55:46) eben: bemasc: That's true. We could hide those from the Journal if we built in support for it. (13:55:50) bemasc: eben: on UNIX systems, files starting with "." are simply not shown by default, according to convention (13:55:56) eben: Oh, I know. (13:55:58) homunq: bemasc: do you mean this: say my tamtam-3-editing activity can open all the other subfiles, just hand it that pile and see what it does with them? (13:55:59) bemasc: ok (13:56:15) eben: My point is the Journal has to add knowledge for that type of thing, if we do that. (13:56:18) bemasc: homunq: I don't understand that sentence (13:56:29) homunq: just a sec (13:56:42) bemasc: eben: yep, but the alternative is that the datastore has to handle an additional metadata system (13:57:04) bemasc: (this, by the way, sounds a lot like Core Data) (13:57:21) eben: bemasc: well, does that depend, too? How is it settable? If we don't expose it in the UI, does it matter if it's just normal metadata? (13:57:42) bemasc: eben: well, then the Journal has to have support for knowing what kind of metadata to show (13:57:50) bemasc: there's no way around writing code for this stuff (13:59:16) homunq: bemasc: how much do you know about Core Data? (13:59:33) bemasc: homunq: nothing. I read the wikipedia entry, though, and it sounds pretty nifty. (14:00:13) homunq: I read the wikipedia briefly, I could not tell if it was some way to keep undo stack, a layer above SQL, or what... (14:00:53) bemasc: homunq: it's a generic high-level data storage system (14:01:09) homunq: definitely has some relation to what we are talking about, but not clear if it has the answers. (14:01:25) homunq: OK, that is not the problem we're solving right now. (14:01:51) bemasc: eben: I think we're pretty clear on this. Develop can implement homunq's semantics over a simple per-file type layer (14:02:12) homunq: Let's reiterate: (14:02:14) bemasc: and the Journal just needs to know which of the files in each instance is The Main File (14:02:54) homunq: the main file = does not show in file list, just in actions list? (14:03:03) homunq: or is that a flag? (14:03:16) homunq: whether it shows or not? (14:03:21) bemasc: homunq: I don't follow (14:03:51) homunq: there are two views (14:03:52) homunq: actions (14:03:53) eben: Just an ordinary file (14:03:54) homunq: and files (14:04:10) eben: homunq: The main file might just be The Image, or perhaps The Text. (14:04:12) bemasc: homunq: "The Main File" is the "Project File". It's the file that defines the instance. (14:04:22) homunq: if the Main File is essentially synonymous with the action, (14:04:26) homunq: exactly. (14:04:31) homunq: two possibilities (14:04:55) homunq: The Project == The Action. The Text = a thing. (14:05:20) bemasc: homunq: have you looked at the Journal mockups? That's what we're referring to here. (14:05:22) homunq: if you have two files, one of which is a project and the other is a text (14:05:44) homunq: I think the project should not pollute the files view (14:05:45) homunq: yes (14:05:53) bemasc: There are two views, one of which shows actions (intances), and the other of which shows objects (files) (14:05:54) homunq: that is exactly what I am referring to. (14:05:54) jwildebo [n=jwildebo@e181078067.adsl.alicedsl.de] entered the room. (14:05:56) eben: homunq: arguable (14:05:59) homunq: want urls? (14:06:00) eben: homunq: consider Record. (14:06:29) eben: You take 10 photos. You get each photo as an object. You get the "roll of film" as an object. The roll of film is the project file. (14:06:46) eben: It seems equally valid to send the whole roll to someone, like an album, as it would be to send one photo. (14:06:49) m_stone: eben: hang on there. (14:07:06) m_stone: the roll of film is more usefully regarded as an "object container", i.e. a set or list of objects. (14:07:33) m_stone: we really want other people to be able to process such containers. (14:07:47) eben: m_stone: sure, in this case it is nothing more. In other cases, the container may have a bunch of other data which talks about how to put together the things it contains. (14:08:03) m_stone: however, there's a lot less value in them building support for parsing records of Record-37's graphical state when it was closed. (14:08:03) bemasc: m_stone: right, and that's why the roll of film is the Project File for this instance (14:08:29) m_stone: for sake of argument, call the latter the ui continuation. (14:08:29) bemasc: m_stone: and that's why I'm suggesting that non-critical state be put in a separate dotfile (14:09:35) eben: m_stone: right, a hidden file, or in metadata....but yes....all state not appropriate for the objects themselves goes elsewhere. (14:09:36) m_stone: http://wiki.laptop.org/go/User:Mstone/Bundle_commentary (14:09:40) m_stone: see the picture at the top (14:09:49) J5 left the room (quit: "Ex-Chat"). (14:09:59) m_stone: and the descriptive paragraph below (14:10:21) m_stone: then, please use the already documented terminology until you demonstrate that this terminology is inadequate (14:10:42) m_stone: (though please comment inline in this page and sign your comment if you think I left out something important) (14:11:15) homunq: OK, sorry, I need to go back for a second. (14:11:57) jwildebo left the room (quit: "Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC."). (14:12:00) homunq: I agree with the decision of this conversation that there is no UI-necessary information in version history, that is not in "what actions can I open" (14:12:10) eben: m_stone: where does metadata/state live in this diagram? As "instance"? (14:12:32) homunq: However, I still like version history because it is compatible with the model of forking versions (14:12:43) homunq: of an arbitrary object (14:12:50) homunq: not just of an activity. (14:13:18) m_stone: eben: UI state lives in the "instance" node. (14:13:22) homunq: My feeling is that the journal UI should support this forking-version model in some way. (14:13:24) m_stone: eben: give me some examples of metadata? (14:13:40) eben: m_stone: well, two flavors of it... (14:13:41) m_stone: eben: e.g. who participated, when they did so? (14:13:55) homunq: OK, it was good for me to say that, (14:14:10) eben: m_stone: creation date, participants, tags, description, activity specified metadata such as number of pages, etc. (14:14:24) homunq: it made me see that they are separate issues. (14:14:32) m_stone: homunq: good. (14:14:33) eben: m_stone: and then there is state metadata for the purpose of recovering the instance (the UI continuation part) (14:15:52) m_stone: eben: sure. well, I tend to think about the problem relationally because I anticipate objects (and object containers, which might themselves be objects; I'm making no commitment here) being referred to from several of these action graphs (14:16:22) m_stone: eben: so I would say that the action has a set of time periods when you worked on it. (14:16:23) eben: m_stone: right, I think we all agree to that. (14:16:39) m_stone: likewise for the objects. (14:16:40) bemasc: eben: really? I thought we were going for copy-on-write semantics (14:17:08) eben: bemasc: that's also true, in general. Complicated.... (14:17:27) eben: bemasc: but consider a Journal entry which is just an action "you sent file X to your friend Y" (14:17:38) eben: That's an action which references X, but does not copy it. (14:17:41) m_stone: bemasc: well, this is where we come down to my suggestion that "bytestreams are our identities; the problem is to record appropriate relations on bytestreams" (14:17:56) eben: In fact, it's not a write. (14:18:04) bemasc: eben: right. We shouldn't say actions=instances anymore (14:18:15) bemasc: eben: I would argue that that action does not have any instance associated with it (14:18:17) eben: But that doesn't mean that we won't have multiple actions referring to the same object (actually, version thereof) (14:18:29) m_stone: bemasc: depends whether the action is resumable. (14:18:45) m_stone: bemasc: actions which can be resumed have instances associated because instances are the actual material which permits resuming (14:18:52) bemasc: m_stone: right (14:18:56) eben: Right, which is why the graph m_stone pointed two has those three nodes in a little triangle. (14:19:23) eben: and why the bundle (needed for resuming) is a child of the instance. (14:19:41) bemasc: m_stone: and what we have further been proposing is that each instance refer also to some specific object as the Main Object (14:19:52) m_stone: bemasc: however, even though I can't resume the (completed) action of sending (A,B,C) to Z, I still want to be able to snag A, (A, B, C), or Z... (14:20:16) bemasc: m_stone: I think that makes sense, so the action should retain pointers to the appropriate objects (14:20:17) m_stone: bemasc: and, at face value, that sounds nuts. (though perhaps I haven't understood your use case) (14:20:36) m_stone: (or your design) (14:20:44) bemasc: m_stone: the use case is determining which activities are capable of resuming an action (14:20:54) m_stone: resuming an action? (14:21:04) m_stone: or processing an object container? (14:21:12) bemasc: m_stone: I'm speaking from the user's perspective (14:21:18) m_stone: don't. (14:21:24) m_stone: one makes a new action, the other doesn't (14:21:29) eben: resuming the instance (14:21:47) eben: which bundles, apart from those linked to the instance within a given action, could be used instead if desired. (14:21:49) eben: (?) (14:22:01) m_stone: bemasc: apologies, the "don't" was a visceral reaction - a segment of "your statement does not typecheck" (14:22:19) bemasc: m_stone: The problem is, I've just used Record to take 10 pictures (14:22:53) bemasc: I now want to view them in a gallery that understands Record's photoset file format (14:23:13) bemasc: how should we think about this? (14:23:14) m_stone: (perhaps because it's a standard List format used throughout Sugar...) (14:23:32) bemasc: one option is to offer a number of activities that can resume this instance (14:23:36) m_stone: You View the photoset. (14:24:08) m_stone: That requires finding a Viewer (an activity), instantiating it and telling the instance to process the photoset, and recording the action of Viewing (14:24:31) bemasc: m_stone: the broader question is: when do we resume instances, and when do we open files and thereby start new instances? (14:24:39) m_stone: (Recall that Activities are usefully regarded as prototypes of instances) (14:24:39) eben: m_stone: right, so we're talking about how to "find the viewer" (14:25:22) m_stone: bemasc: there are two formulations. I don't yet have a strong preference between them. (14:25:42) bemasc: m_stone: we are trying to come up with a way to make this determination (14:25:56) m_stone: a) Activities can be used to synthesize instances ready to process some objects. It's just part of what Activities are. (14:26:28) m_stone: so we might use this ability to get an instance attached to our roll of photos which we can "sume" for the first time (since we're not really RE-suming it...). (14:26:34) m_stone: ;) (14:26:34) bemasc: m_stone: and one suggestion is that each instance should identify one of its files as the "project file", and any activity that can open this file can be shown in the UI under "Resume with..." (14:27:24) m_stone: the other option is to say that Activities can be performed on objects and that this creates an Action which, just as a quirk of activity implementation, probably has an instance associated with it that can be resumed. (14:28:09) bemasc: m_stone: I don't understand, as usual. Do you mean Activities can be performed on object containers? (14:28:27) m_stone: I mean that I can Paint on a collection of photos. (14:28:34) bemasc: m_stone: no you can't (14:28:38) m_stone: I think that's a plausible, grammatical statement. (14:28:39) bemasc: m_stone: you can Paint on 1 photo (14:29:10) bemasc: Paint has no idea what to do with an object container containing 10 PNG files (14:29:12) m_stone: bemasc: a technical limitation of the version of Paint we've got at the moment. You prefer that I can Gimp a collection of photos? (14:29:34) m_stone: bemasc: but I agree that my original statement did not typecheck. (14:29:54) bemasc: m_stone: you're being way too abstract for me to follow you (14:30:02) m_stone: ah. apologies. (14:30:14) m_stone: eben: have I lost you as well? (14:30:30) eben: m_stone: Only inasmuch as I don't know what point you're driving at with the example. (14:32:09) m_stone: that "resume with" is either nonsensical (because instances resume and do nothing else) or that what "resume with" should mean is "use <___> as a prototype to make a new instance which, when resumed, will be attached to objects <---->" (14:32:23) m_stone: since activities are logically quite similar to prototype instances (14:32:58) m_stone: in that they offer some fixed UI continuations which can be combined with zero or more objects (14:33:19) m_stone: i.e. they tend to have a default "initial UI" that they use when instantiated. (14:33:49) bemasc: m_stone: nobody else here as written a program in a prototype-based language, so please use a different metapho (14:33:59) m_stone: bemasc: never used javascript? (14:34:09) bemasc: m_stone: oh, didn't know that (14:35:07) m_stone: bemasc: here's another small example: http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Objects-Overview (14:35:28) m_stone: (for future reference. :) ) (14:35:48) bemasc: m_stone: "resume this instance with Activity A" literally means "start Activity A and tell it to open this object container" (14:36:05) m_stone: bemasc: that's how it's implemented today. (14:36:21) m_stone: bemasc: why not just make the "instance" an executable program instead? (14:36:31) arjs left the room (quit: Read error: 104 (Connection reset by peer)). (14:37:01) bemasc: m_stone: that doesn't mean anything. Anything can be called "executable". (14:37:05) m_stone: (actually, I've got an answer for you, but it's a matter of rainbow implementation details) (14:37:32) m_stone: woah, I think I misread your statement. (14:37:34) bemasc: I can declare that my PNG files are executable, and I think I can even patch my kernel to handle them as executables (by opening them in the GIMP) (14:37:37) m_stone: resume this "instance" with activity A? (14:37:45) bemasc: m_stone: right (14:38:03) m_stone: According to my grammar, you should mean "resume this instance|". (14:38:11) bemasc: m_stone: I do not support your grammar. (14:38:20) mtd: m_stone: I think I see the continuation analogy (or philosophy), but pretty much in practice you're not describing something much different than what bemasc is. (14:38:33) m_stone: The "with acitivity A" seems nonsensical. Instances are not parametric over activities. (14:38:44) mtd: given the stack = the metadata and the runtime = a new instance of an activity. (14:38:46) bemasc: m_stone: they are if we decide they are. (14:38:59) m_stone: bemasc: why is the resulting UI a good one? (14:39:25) bemasc: m_stone: mostly because we have no distinction between object containers and instances in the UI (14:39:37) eben: m_stone: agreed on the grammar.... (14:39:46) eben: m_stone: we don't have a good solution. (14:39:49) m_stone: eben: that you do not yet support it? (14:39:53) eben: We considered "as activity A" instead... (14:40:15) eben: no, regarding "resume with" being the wrong speech for the intended meaning of the operation. (14:40:25) m_stone: eben: good. (14:40:29) bemasc: m_stone: the question is really "what should resume mean from the user's perspective?", and I think the answer is "I want to keep working on this abstract project" (14:40:54) bemasc: where the abstract project is concretely represented by an object container, not by any particular activity. (14:41:16) m_stone: bemasc: totally agreed. however, "project" should concretely mean "crazy UI data that I never expect anyone else to deal with" rather than "useful group of objects which lots of other things can deal with" (14:41:32) m_stone: (our comments interleaved poorly there) (14:41:46) m_stone: My comment referred to your 14:40 statement, not the 14:41 statement. (14:41:58) bemasc: so this is the crux of the matter (14:42:07) m_stone: well, of _this_ matter. :) (14:42:08) eben: Actually, project in his meaning was "the file which describes what to do with the useful group of objects" (14:42:20) m_stone: eben: "his" ---> ??? (14:42:28) bemasc: I think a use case is in order (14:42:56) m_stone: bemasc: I wrote one on my bundle commentary page. (14:43:01) eben: m_stone: his == bemasc, the comment you had contention with (14:43:04) bemasc: I write a webpage using the Dreamweaver activity. It's a collection of files, with one HTML file but also CSS and jpeg's (14:43:14) m_stone: bemasc: a simple collection of objects does not innately specify an activity I can use for processing those files. (14:43:15) bemasc: then I decide that I want to view it in the Browser (14:43:34) bemasc: then I decide that I want to edit the CSS by hand in a text editor (14:43:34) m_stone: on the other hand, an instance is navigable to the activity that is its prototype. (14:43:41) bemasc: then I decide I want to open it with dreamweaver again (14:43:44) eben: m_stone: That's the point of the "project file" in the first place. There *is* something that takes on that role. (14:43:55) m_stone: that way, if I want to have another instance of recording on "fish" instead of "butterflies", I can get there from the instance. (14:44:04) m_stone: I can get there from the action of recording butterflies. (14:44:08) eben: And which advertises it's mime-type so other activities can be instantiated from the objects. (14:44:35) m_stone: but I'm not connected solely to Record from the collection of objects. (14:45:12) m_stone: In fact, if record has no photoediting capabilities, I'm might not ever find it adjacent to the photos in the UI. (14:45:54) m_stone: eben: your last comment did not parse. (14:46:27) m_stone: bemasc: what's your question? (14:47:12) bemasc: m_stone: first: how do I open the webpage with Browse? (14:47:21) eben: m_stone: each instance has "a collection of objects" associated with it. one of those is flagged as "the primary object", such that other activities can be instantiated with it as necessary. The primary object knows what to do with "the collection of files" (14:47:22) m_stone: bemasc: you've got tree-structured data. All of our "object containers" to date can be represented as plain old directories. (14:47:41) bemasc: m_stone: right, but how does the Journal know that Browse can open this object container? (14:47:41) eben: m_stone: I don't think that's true. (14:48:14) eben: m_stone: the photos example is a case where the container is empty apart from its contents.... (14:48:34) m_stone: eben, bemasc: I suggest you draw some labelled graphs of the progression of data through your use case. (14:48:46) m_stone: it will be much easier to discuss specific diagrams. (14:48:59) bemasc: m_stone: I am much more interested in working from the user's perspective (14:49:15) m_stone: bemasc: then draw your diagrams from the user's perspective first. (14:49:22) bemasc: what should a user have to do, after having put together a webpage in a creation activity, to view it in the Browse activity? (14:49:22) eben: m_stone: but an HTML instance might have several images, a few sounds, and a video in its object collection, with a HTML file treated as the "object container", including the necessary code to put it all together. (14:49:30) m_stone: bemasc: and translate beneath them into the dataflow perspective. (14:50:22) m_stone: bemasc: begin the action of Browsing the Web-page. (14:50:44) bemasc: m_stone: right. So which button would that be? (14:50:47) eben: you can open the HTML file in the Dreamweaver activity again if you want. You can open it with Browse which will know how to display it. You could open it with SimpleWrite, which would ignore the other objects and just show you the source code. (14:51:12) bemasc: eben: but the HTML file alone will not open correctly in Browse, and this is my key point (14:51:40) m_stone: bemasc: I'm sorry, but text in IRC is not cutting it for me. I'm just not understanding what you're getting at. (14:52:00) m_stone: bemasc: please provide a diagram, or adapt my diagram and show where the fault occurs. (14:52:14) bemasc: m_stone: I cannot diagram this (14:52:35) m_stone: bemasc: can you write a paragraph instead? (14:52:36) eben: bemasc: why wouldn't it open in Browse? (14:52:45) bemasc: eben: because the HTML file is missing the CSS and pictures (14:53:00) bemasc: eben: so it might open, but it would be missing lots of pieces (14:53:11) eben: bemasc: no, all that stuff is contained in the "useful objects collection" of the instance, right? (14:53:12) bemasc: eben: Browse needs to be able to open the whole "object container" (14:53:22) eben: Why shouldn't browse be able to reference thse? (14:54:21) bemasc: eben: because HTML refers to images by paths, but those pictures won't even be visible in the filesystem to Browse (14:54:24) eben: If I have an HTML file and an image on my Desktop, the former referencing the latter, and I open that HTML file, it will work fine. What's the difference here? (14:54:51) eben: Why not? If not, how are they even accessible to Dreamweaver when you resume it!? (14:54:51) bemasc: eben: the difference is that in this case, that image won't even be in the filesystem as seen from the perspective of Browse (14:55:17) bemasc: eben: activities can only see the specific files that they have been told to open (14:55:24) eben: That's the whole point, here, right? Store the objects out individually so other things can use them, but keep the references so that things work with respect to instances. (14:55:42) bemasc: eben: you can't modify the HTML file to include references, or it won't be HTML (14:55:50) bemasc: so instead, we create a "container" (14:56:08) bemasc: I imagine it as a .tar file containing the HTML file, the pictures, and the CSS (14:56:11) eben: :-/ Then what good is this? (14:56:18) bemasc: if you open the .tar file with Browse, it works (14:56:24) bemasc: because it has all the components (14:56:31) bemasc: if you open just the HTML file, you get just the HTML file (14:56:37) eben: bemasc: But the tar file doesn't have type HTML (14:56:52) bemasc: eben: but it does, because we designate the HTML file as the "project file" for this container (14:57:15) eben: No, if that were the project file, then that's what would open with Browse. (14:57:17) bemasc: Browse advertises the ability to read HTML, and this .tar file is listed in the datastore as containing a project file of type HTML (14:57:34) bemasc: so the Journal offers the user the ability to open this .tar file with Browse (14:57:48) eben: bemasc: So you're proposing that every "collection of objects" is a tar file instead. (14:57:49) bemasc: when the user accepts, the datastore unpacks the tarfile into Browse's directory (14:58:04) bemasc: and then points it at the project file, which is HTML (14:58:13) bemasc: eben: not specifically; there are many other implementations (14:58:29) eben: bemasc: OK...but you're talking the technical side. The user doesn't know this was ever tarred. (14:58:32) bemasc: eben: right (14:58:36) eben: They can still see each, and interact with each object. (14:58:38) m_stone: eben: he's just saying it to give your mind the flavor of the packaging-of-related-stuff-together (14:59:01) bemasc: eben: right, but interacting with the HTML file itself is very different from interacting with the whole collection of files (14:59:37) eben: indeed! (14:59:46) cafl left the room (quit: Remote closed the connection). (15:00:23) m_stone: bemasc: the Browse-displaying-website example is really the "interact with this html file in the context of this larger collection of stuff" (15:00:27) eben: but, this poses some problems for the UI.... (15:00:32) bemasc: m_stone: right. Context is key (15:00:38) eben: Consider a Journal entry for this instance...this HTML instance. (15:01:12) eben: It might read: "Today you created This_HTML_File, which contains Image_1 and Image_2" (15:01:18) m_stone: bemasc: so I agree that Browse can use some hints. But I think that Browse _has_ to be able to deal with non-hinted material because it's certainly going to encounter it both because of design changes and because of dumb media like USB keys (15:01:42) m_stone: bemasc: I tend to think of the hint as an xattr, keyed by mime type, attached to the top-level dir representing the container of stuff. (15:01:44) eben: Now, the way to resume this directly is to click on This_HTML_File. (15:01:56) m_stone: bemasc: i.e. it says "dear people looking for HTML - start looking here" (15:02:15) m_stone: "love, the Dreamweaver activity" (15:02:34) eben: One would expect clicking that to resume the instance....not open it independent of the images. (15:02:58) bemasc: eben: I'm looking at your Designs/Journal (15:03:01) eben: What, then, if I hover and wait for the palette to appear, to do "resume as" (or whatever we call it)? (15:03:21) m_stone: eben: "act on with" (15:03:24) bemasc: eben: It has two views: action view and object view (15:03:39) bemasc: eben: the action in question shows 4 files (15:03:46) eben: ok (15:03:52) bemasc: if you choose to resume the action with Browse, you get all 4 files (15:04:01) bemasc: and the webpage consists of a combination of all 4 files (15:04:06) m_stone: bemasc: ARGH. be grammatical. (15:04:10) m_stone: bemasc: :) (15:04:33) m_stone: bemasc: if you choose to act on all four files with Browse, you want to get a webpage full of pictures and CSS. (15:04:36) bemasc: yes (15:04:56) bemasc: alternatively, if you choose to act on just the HTML file with Browse, you'll get just the text, no formatting or pictures (15:05:13) bemasc: or if you choose to act on just the picture with Browse, you'll get just the picture (15:05:21) eben: bemasc: back up a step. "choose to resume with Browse"... (15:05:24) eben: How do you do that? (15:05:32) bemasc: and you can't open just-the-css with Browse, because it doesn't support that type (15:06:07) m_stone: eben: I "asked" the same thing. I suggested that bemasc really meant "when you decide to act on all four files with Browse" (15:06:12) bemasc: eben: I'm actually not sure, because I don't see any way to resume an action in Designs/Journal (15:06:27) eben: My point here is, looking at the mockup, "Rain Forest" is the "roll of film", and it is likewise the Project File (15:07:14) bemasc: in other words, the project file is hidden (15:07:33) eben: bemasc: Well, right. The main point to recognize there is that the instances are represented as the activity icons. The objects are thumbnails (or a similar treatment, as seen in object view, which contains the activity icon on a "page") (15:07:35) m_stone: eben: my suggestion is that you pull the representation of the object container (holding the four objects) [sic: dir holding four files] onto the Browse activity. Or you select Browse from the list of activities to act on this data with, (where we suggest it either because of an explicit hint or because we suggest all activities which can process any file contained in the group) (15:07:39) bemasc: or one of the pictures is designated as the project file (15:07:56) eben: bemasc: The intent was to make resuming an instance as simple as clicking on the primary file which represents it. (15:08:01) m_stone: bemasc: that's a really bad design. (15:08:05) m_stone: bemasc: you're going to want more than one of them. (15:08:27) eben: Of course, each object (including the primary file) has a little "details" button next to it, which takes one to the detail for the object (independent of any instance at all) for acting directly on the object itself. (15:08:34) bemasc: m_stone: I don't know what you're referring to. I'm just attempting to figure out what's going on in slide 2 (15:08:50) m_stone: bemasc: I'm saying that the idea of "a single designated Primary Object" is folly. (15:09:02) bemasc: m_stone: it's necessary (15:09:09) m_stone: bemasc: for two reasons. (15:09:29) m_stone: bemasc: one because you're going to want more than one of them. and two, because you can't guarantee that it will exist in the presence of dumb media. (15:10:00) eben: m_stone: in dumb media, every "instance" is associated with one and only one object. (15:10:04) m_stone: so, in my opinion, you have no choice but to design a UI which does not depend on their existence in order to function. (you should, however, design a UI which takes hints that it can find) (15:10:15) eben: What does it mean to want more than one? Doesn't that just imply you have two instances? (15:10:23) m_stone: eben: take the web-page example. (15:10:38) m_stone: eben: it has some html, some css, and some photos. (15:10:56) m_stone: maybe you're lucky enough to have AwesomeEditor [etoys?] that handles all three. (15:11:16) m_stone: eben: however, in practice, you're likely to want to mix and match. (15:11:19) m_stone: right? (15:11:56) eben: m_stone: mix and match in what sense? One could "open" any of the objects independently. (15:12:11) m_stone: eben: but some of them must be opened in context in order to make sense. (15:12:45) m_stone: I can probably cook up an example that obviously has two different kinds of objects which need to be opened in context to make sense, but let's go with this one for the moment. (15:13:07) bemasc: the abstract "Webpage" consists of all 4 files. If you want to start an activity instance to view the webpage, that single instances needs to have access to all 4 objects. (15:13:14) m_stone: eben: an essay containing labelled diagrams is an easy example. (15:13:32) eben: in what context? Either I care to look at the collection as a whole, for instance, in Dreamweaver, or I care to look at a single object from the collection. (15:13:35) bemasc: so one object = one instance won't work (15:13:45) bemasc: eben: I agree. (15:13:56) bemasc: eben: the problem is, the UI has no way to open a collection (that I know of) (15:14:17) eben: bemasc: But you just got through proposing the tar approach for getting around that internally (15:14:19) bemasc: eben: the only way one ever opens a collection, in the mockups, is to "resume" an activity (15:14:27) bemasc: eben: sure, but I'm talking about in the UI (15:14:48) eben: Ah, yes. (15:14:50) bemasc: the hard part here is design, not implementation (15:15:02) bemasc: (we have hard implementation problems elsewhere) (15:15:08) m_stone: :) (15:15:11) eben: The only way to *use* the collection of objects is to do so from its corresponding action entry, naturally. (15:15:17) bemasc: right (15:15:20) m_stone: eben: how do you mean? (15:15:43) m_stone: eben: consider turning a roll of photos into a slideshow (15:15:53) eben: In these designs, the implicit assumption was that the "primary object" served as a standin for the instance itself, which when clicked on resumes the instance. (15:16:08) bemasc: you mean a stand-in _in the UI_ (15:16:12) bemasc: I hadn't thought of that (15:16:32) eben: In the same manner, that object would be the thing which had a "resume this instance as activity X" option in its palette (15:17:21) bemasc: eben: but every object can be opened by other activities (15:17:26) eben: In other words, the representation of the primary object in the design is *as* the instance... (15:17:35) bemasc: so one object can be opened or resumed, and these mean different things? (15:17:37) eben: bemasc: Right, so there's a hole in the system, right? (15:18:05) m_stone: eben: well, how does the photoroll -> slideshow example work? (15:18:16) eben: You can act on that thing either as the instance, or as the object. So maybe that's busted. Maybe we need to in fact represent it "twice" in the UI. (15:18:52) m_stone: eben: furthermore, suppose I resume the action of photographing butterflies. Presumably, the next time I edit my slideshow, I'd like to be reminded that there are new butterfly photos. (15:19:01) eben: Maybe, for instance, that slide should also have a "Rain Forest" *object* down below, with a preview...(a contact sheet, let's say, with the 4 images on it) (15:19:57) bemasc: eben: what I want is a way for the user to open a collection (15:20:25) bemasc: eben: Currently, collections are only represented, as actions, so I've been using the word "resume" to refer to opening a collection (15:20:40) m_stone: (and, in future work, pay attention to changes made to that collection [or to new versions of it that appear, etc, etc) (15:20:50) eben: currently, meaning in the designs we're looking at, right? (15:20:55) bemasc: eben: yes (15:21:41) eben: Right, as an aside, another missing component of the current design (a big one) is that there is no way to say "show my all versions of this instance" (15:21:54) eben: The current design only really has versioning for objects, not instances. (15:22:07) m_stone: eben: at the big Journal meeting w/ marco, tomeu, bertf, &co. we definitely discussed being able to use collections as part of several actions. (15:22:22) m_stone: eben: not "collections", you mean? (15:22:43) m_stone: eben: :) (15:23:24) eben: Ummm, I don't know? (15:23:32) m_stone: fair enough. :) (15:23:35) bemasc: it depends on what the metaphor is (15:23:49) eben: I mean, if I resume an instance 5 times, make changes each time, and then want to see the chain of actions I took to get to where I am. (15:26:00) bemasc: and let's not forget the problem of figuring out which version of an activity can resume an instance, which is how this conversation started (15:27:26) eben: I feel like we've gotten about nowhere in an hour. (15:27:29) m_stone: bemasc: (a problem with at least one easy solution, namely, to regard instances as executables derived from some prototype...) (15:27:35) m_stone: eben: you're wrong. :) (15:28:02) eben: Perhaps we need to have an in Cambridge meeting to resolve all of this, going through the posted Journal designs and hammering it until we have a solution for all these issues. (15:28:10) eben: m_stone: I'm glad I'm wrong! (15:28:19) m_stone: eben: we had a nice synchronization of terminology. we know of a use case - record butterflies, make slide show, record more butterflies, update slide show - that it's not quite clear how the present design would represent. (15:28:36) bemasc: (I thought you guys already _had_ this meeting, 7 months ago) (15:28:44) m_stone: we also have the make website - view website - edit images - edit html - view website sequence. (15:29:37) m_stone: and the thoughts derived from consideration of that use-case, namely, that our UI will work much better if we attach some hints to collections but that we cannot rely on the existence of these hints. (15:29:48) eben: bemasc: We did. It resulted in the mockups you see. Which still aren't perfect! (15:30:08) m_stone: eben: they don't need to be perfect. they've already allowed significant progress (15:30:18) m_stone: eben: they're mockups for a reason! :) (15:30:24) eben: m_stone: right, both of those use cases are not covered, at present, by the design. (15:30:42) eben: Mostly because we don't have aliases/references in that sense at all. (15:30:50) m_stone: eben: so we should explain that clearly on the design and send some email so the rest of the world can think about it. (15:31:00) eben: m_stone: certainly, that's my point, and why I think it's worth another meeting to make them better. (15:31:06) m_stone: probably with a cleaned-up summary of this conversation like the previous ones I've written. (15:31:47) m_stone: eben: could be, so long as we record it and summarize it the same way. (15:32:38) m_stone: eben: did I convince you that you were wrong? (15:32:51) m_stone: (about the claim that the last hour was wasted) (15:33:41) eben: m_stone: Oh, I didn't say "wasted". I said that we hadn't gotten far (really, raised more questions than answered). Yes, I think it was productive nonetheless. (15:34:12) m_stone: ah. I misread you. (15:34:42) m_stone: "about nowhere" is very evocative. (15:34:54) eben: As an interesting option, by the way, we could consider making the way you act on an object contextual to where you initiate the action from. For instance, if I "open" an image in an HTML instance from that instance, maybe it actually saves "in place" by just creating a new version of that instance, with the appropriate file changed? (15:35:34) eben: Whereas "opening" the object from within object view would treat it wholly independently, and use the copy-on-write approach to create a new instance for the changes. (15:35:47) m_stone: eben: I didn't quite follow that comment and I need to relocate to 1cc anyway. (15:36:01) bemasc: eben: I think I get it. Interesting... (15:36:13) m_stone: eben: sounds like it's worthing reflecting on though. (15:36:52) m_stone: if I undertake to summarize this discussion, it will probably take me until the weekend. (15:37:02) bemasc: eben: it sounds like it might be easy to break things though. For example, a Desktop Publishing application might record the dimensions of all its images, and fail to load them properly if the dimensions change unexpectedly (15:37:21) HoboPrimate: can't the use case of creating a new instance of an object be taken care by copy+paste and/or "Keep as New" within the activity? (15:37:29) m_stone: do you want me to do it or does one of you fine gentlemen prefer to take the honor? (15:39:01) ***bemasc is trying to get other things done today, but ... maybe (15:39:53) eben: m_stone: I don't think I'd get to it any sooner than you. Also, from past experience, I trust your ability to accurately summarize and categorize the meaningful bits better than I could. (15:40:30) m_stone: very well.