User:Mstone/Commentaries/Bundles 2
Contents
Sugar Data Model
Broken Threads
homunq> eben - I want to start coding new activity bundle format, do you have
a minute to talk about your UI vision there?
eben> homunq: Sure, let's do it.
homunq> Is it worth including enough info to reconstruct "broken threads"?
(recall: forks are one case of "broken threads".)
eben> I not convinced that broken threads should be reconstructed. I
personally feel that a broken thread should be treated as a separate
activity. Should the "original version" be an activity on the other
side of a break?
homunq> The principal reason I think that broken threads are worth it is that
they make our security model more in-line with reality and thus more
secure - people will have less need to subvert it in order to achieve
their goals.
homunq> I imagine that the user has some easy way to explicitly update her
favorite version and to explicitly update instances when a "newer"
activity becomes available that crosses a break. This is because the
newer version implicitly lives within an unbroken thread and you can
explicitly say "use the original version" if it is available. I also
imagine aggressive backups of activity versions so that if you have
server coverage, then chances are that you can get the original
version. Note: the original version could not be on other side of a
break because the only way to cross a break is to open and opening
saves a new version of the instance. Thus only the old instance would
have an old original version.
eben> 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. Let's work through an
example:
eben> Consider activity A.
homunq> A exists in version Ax.1, Ax.2, and Ay.3
eben> right, perfect.
homunq> so you have an instance of Ax.1 and then you get Ax.2. Your instance
will now automatically open using Ax.2.
eben> now, Bob comes along, guts A and derives Ay.1
homunq> No... the rules would be that version number keeps increasing. Now
you get Ay.3. Something derived from Ax.1 is Ay.2 Or in our example
Az.2 because y is taken.
eben> homunq: But this is the point we disagree on. You say that it
increases, because the "identity" doesn't change. I say that it
starts at one, because it's effectively a new activity.
homunq> OK. So whose example are we following?
eben> Well, I'm trying to contrast them.
homunq> I say mine, because the burden of proof is on me.
homunq> So you get Ay.3. Now if you just run your instance, it still runs as
Ax.2 but it has an extra button in the journal called "update me".
eben> Ay.3 did not get auto-favorited, even if Ax.2 was already favorited.
homunq> The palette or something on that button says "Ay.3 claims to be a
newer version, but I cannot be sure" - some message that conveys the
alleged nature of the relationship.
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?
homunq> Favoriting and instances are two different (but related cases), I'm
talking instances right now - but yes, they could do it manually. I
just think it's nice to have the button.
eben> And why do you think it's safe to tell the kid that this is a "new
version"?
homunq> I think it is safe to say "claims to be a new version"
homunq> Note:
eben> How does it claim this?
homunq> implementation detail
eben> Does the activity retain the same service name?
homunq> No.
eben> It has a new service name?
homunq> The service name is not user-readable. It can have same or different
user-readable name. However, it has a list of previous service ID's
and version-of-forks.
eben> Who cares if it's exposed? In your model, does Ay.3 have the same
service name as Ax.2?
homunq> No. The identifiers you call "service names" are associated with
"unbroken threads". They change across breaks.
Heritable Traits
eben> 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? 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? I think that activity thread deserves to have a sense of
ownership associated with it.
homunq> I think that it is perfectly fair, if you give users explicit choice.
eben> No, I don't think that's fair at all. 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"...
homunq> I think that people sometimes want to assert that and sometimes have
good reasons for wanting it without having good reasons for getting
the x signing key.
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. That's why I
personally like calling it Ay.1 (The first version of an alternate
thread), even if it was based upon something else.
homunq> Then what about Az.1 which inherits from Ay.1? How does it say that
Ay.1 is a later ancestor than Ax.2? That is what the monotonic
versions are for.
homunq> There is another bit I have to explain. In my model, there are
private instances. Any instance marked private cannot be opened by an
activity which has P_NETWORK unless it has the same service ID as
creator.
eben> Any instance that has not been shared?
bemasc> The key thing here is that Eben is also proposing that instances be
explicitly mime-typed. Furthermore, the type of an instance created
by "Ay.2" is not "Ay.2"; rather, it's "xml/tamtam-projectfile". Then,
if you change the format in an incompatible way, then you should
introduce a new "mime type" to describe the new format. (possibly not
an actual "mime" format, but some kind of project file with type).
homunq> Is there any support for format versioning in mime types? In
particular, how do you define "incompatible"?
eben> I'm not sure... do we need full ancestry across threads? 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?
homunq> This is a problem for me. If you add a new bit of data that does not
break the old activity, but is not supported by it, how is that
indicated in mime-type-land?
bemasc> If it breaks the spec for that filetype, it's a new filetype. That's
the author's decision.
eben> Incompatibility certainly comes as a responsibility, in my mind, of
the author of the thread.
homunq> I think that most format changes are in the grey area of
compatibility.
bemasc> That's why it's the author's decision.
Types vs. Inheritance
eben> Consider taking Ax.2 (because you love the interface) and on purpose
explicitly swapping out all of the data formats/protocols used for
your own. 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? They are authored by two separate
people who may not even know each other.
homunq> In that case, your new activity is not a child version.
eben> I claim that this decision can only be intelligently made when you
restrict the scope to a single thread.
homunq> Exactly, stand alone.
homunq> Sorry - we are talking about two things - mime type and activity
ancestry. I do not want ancestry to be an archeological record of
code origin.
homunq> If you change file formats incompatibly, then you should start a "new
activity", even if it has same user-readable name.
bemasc> Ancestry does not imply compatibility. Witness MS Word. Conversely,
witness AbiWord, which is by no means descended from MS Word, but
(relatively recently) got .doc import capability. The question is:
what can ancestry tell us? Alternately, what actions can the system
take on the basis of ancestry? You seem to be proposing one action
the system can take on the basis of ancestry: determining which
Activities are capable of opening which files. 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.
homunq> Correct on both counts. I also think that the shell should give the
user a prominent option to open old instances with the child
activity.
bemasc> I still prefer explicitly typed instance formats.
homunq> Explicitly typed but not versioned?
bemasc> If you've broken compatibility with the previous versions, you should
declare a new instance format (or increment your version format
number)
homunq> mime types have a version number?
bemasc> you can just add a number on the end, if you want.
bemasc> I think formats should be versioned entirely separately from the
activity bundle itself, and possibly with no assumption of backwards
compatibility.
eben> 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.
bemasc> homunq wants to use a non-secured ancestry system to determine
instance compatibility. This amounts to declaring that the type of an
instance is the specific version of the activity that created it.
Then another activity can declare "I can open that instance" by
listing that activity version as one of its ancestors.
homunq> I also want it because I think that if we do not provide an un-
secured (and thus un-trusted) mechanism, then I think that developers
will feel undue pressure to use the trusted mechanism in
inappropriate ways.
eben> Wait wait....I find your last comment disagreeable, bemasc. 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....
bemasc> 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. Also, we can have 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.
eben> That seems arbitrarily limiting, no?
homunq> Note that multiple inheritance is possible. Also, Ay.10 can say "I
save in format Ax.3".
bemasc> Conversely, in eben's proposal, instances are handled just like
files, in terms of typing. Thus 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 so then activity A.10 might not be able to open instances
of A.3.
eben> What if these activities have no idea each other exists, but they
share a common format? They should "just work", and the system should
know that they can handle each other's formats.
bemasc> eben: I agree, which is why I prefer your proposal. Also, homunq's
system can be implemented easily inside eben's.
eben> It seems absurd that a simple activity that writes a text file could
produce something that can't be opened by any other text editor
created in the past or future.
homunq> Of course. That is why I keep saying "actions are not files". The
text file can be opened by any text editor. "I emacsed that" and "I
wrote that" are not interchangeable but the resulting text files are.
eben> Instances with all associated metadata and goodies? I guess we
haven't ever had the notion of an "instance type" to be honest....
bemasc> That's because we haven't had a distinction between files and
instances.
homunq> In your new journal spec with actions, the difference is much more
clear.
Project Files and Metadata
What is an instance?
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.
homunq> That makes no sense to me. An action can have multiple, incompatible
files associated.
bemasc> You imagined a scenario in which each instance was associated with a
"project file".
eben> Yes. I think each instance will have a "project file", and that
project file will have a type. In my head though, that type was TXT
or PDF or PNG or HTML....
bemasc> Aren't TamTamEdit's project files are going to be some complicated
custom format?
homunq> Also, in my head, the instances/actions had some of their format in
metadata - or is that abusing metadata?
bemasc> I think metadata should only be things that the user is invited to
mess with
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.
homunq> What about things like screenshots? Changing it could be a security
hole and I can't think of a positive use case.
bemasc> Changing the screenshot won't screw up the instance. 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".
homunq> bemasc: that is a fair rule.
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.
bemasc> project files are almost always application-specific. The example in
my head is Audacity.
eben> I think that's about a 50/50. In the case of an Audacity instance...
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
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). But, there still is a file, and it still has a format, and other
activities could certainly adopt it in the future.
bemasc> the project file format is specific to audacity, and is occasionally
changed in a non-backward-compatible fashion
homunq> good example. that stuff clearly is not metadata despite what eben
and I vaguely thought.
Audacity example
bemasc> So the question, for me, is UI. If someone writes an Audacity-
compatible Activity, what should users do to continue their work in
this new program? Is that an example of resuming your work, or an
example of starting a new instance?
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.
homunq> why not keep the tab in that project?
eben> Because that info is specific to the UI of the activity, and the
platform that the activity runs on.
eben> I have audacity for OSX. It doesn't have tabs. It probably has a
completely different and perhaps incompatible UI.
homunq> OK, so actions have 4 kinds of data: files, projects, view settings,
and genuine metadata (tags). I'd rather not assume that any of those
are equivalent. If an activity author wants to assume that, fine.
eben> I actually see 3 myself: associated files (of which one is the
project), state blob, and metadata. In practice, the state blob might
be some piece of inaccessible metadata.
eben> Consider a painting program. Clearly you want the "project file" to
be simply an image, for the best portability. Storing the currently
selected color would be metadata. (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.)
homunq> "Inaccessible" is the point. This is different in some key way from
normal metadata. The implementation can be the same though.
bemasc> What about undo history?
eben> That would be part of the state too, right?
bemasc> Well, that's the question. An image editor clearly doesn't store the
undo history in the image.
bemasc> (or does it? the PSD format stores undo history, I think, and so does
gimp's XCF)
homunq> in a perfect world, undo history would be in olpcfs ... bemasc> homunq: I agree. homunq> I'm actually kinda serious.
UI Decisions
bemasc> I'd like to work from the UI down. 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?
homunq> There is a "just resume" button: you click it, it defaults to
something. If you hover over it, it gives you choices.
eben> (It resumes with the last activity you used for that instance.)
bemasc> If there's a new version, does it use the newer version?
eben> bemasc: I would argue yes, if it is part of the same thread.
homunq> (If there is a new version AND the new version can open that data).
It seems that the data has a master file which gives it its format?
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. (again, assuming it can.)
bemasc> What if there are no more activities installed in the thread, but
there is another activity installed that can resume it?
eben> In that case, we probably (currently) pick the next in the list.
bemasc> what if I want to resume with a non-default activity? (or a non-
default version)
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. If you want to do that you use the
secondary palette of the resume button, which lets you choose
anything that supports the type.
bemasc> That all sounds pretty reasonable to me.
eben> One option for the non-default version case is to say that the list
is actually hierarchical (one level). If there are is 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.
homunq> I have a problem with that: what if you have 5 versions in the same
thread? Do they all clog up that list?
eben> No, the versions that are in an unbroken thread are treated as "one
thing" until you ask for more info. This is the same as what I
intended to represent in the activity list in home. They would be
grouped by unbroken thread. 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).
bemasc> It sounds like the system has the following: each instance is a
collection of files, one of which is declared the "main file". Each
file has an explicit type. Each instance has "application metadata"
and "user metadata". 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.
eben> not worth or not appropriate (in the case of trying to adhere to
already defined formats)?
homunq> There are several issues this does not address... what if format
tamtam-project5 can be opened imperfectly by tamtam-project3?
Obviously tamtam3 cannot preemptively say this. What if different
subfiles have different levels of privacy? (I am thinking about
private signing key for an activity bundle.)
bemasc> We could allow files to have multiple types.
eben> In the worst case, TamTam5 could include a way to export a TamTam3
file/instance
bemasc> 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. Then make image.png the
project file.
eben> instead of the state blob as metadata?
bemasc> yes - the "activity metadata" could easily be stored in a file other
than the project file, without breaking compatibility
eben> 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.
bemasc> JSON is fairly human-readable. We could also adopt a "dotfile"
convention like the one used in all UNIX systems.
eben> 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.
bemasc> Hiding things from the user is generally bad, but the "activity
metadata" would be hidden from the user anyway.
eben> My point is the Journal has to add knowledge for that type of thing,
if we do that.
bemasc> yep, but the alternative is that the datastore has to handle an
additional metadata system
eben> 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?
bemasc> well, then the Journal has to have support for knowing what kind of
metadata to show. there's no way around writing code for this stuff
homunq> What if I have an tamtam5 instance and an app I like which opens
tamtam3, but I do not have tamtam5 activity.
eben> That is a *really* tricky question....it's part of the reason that we
didn't use aliases at all in the past...
bemasc> (this, by the way, sounds a lot like Core Data)
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...
bemasc> it's a generic high-level data storage system
homunq> definitely has some relation to what we are talking about, but not
clear if it has the answers. that is not the problem we're solving
right now.
bemasc> eben: I think we're pretty clear on this. Develop can implement
homunq's semantics over a simple per-file type layer and the Journal
just needs to know which of the files in each instance is The Main
File
homunq> Does the main file show in file list or just in actions list?
eben> It's just an ordinary file - the main file might just be The Image,
or perhaps The Text.
bemasc> "The Main File" is the "Project File". It's the file that defines
the instance.
homunq> there seems to be confusion. if you have two files, one of which is a
project and the other is a text, then I think the project should not
pollute the files view
Examination of Use Cases
eben> consider Record. 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. It seems equally valid to send the whole roll to
someone, like an album, as it would be to send one photo.
m_stone> hang on there. the roll of film is more usefully regarded as an
"object container", i.e. a set or list of objects. we really want
other people to be able to process such containers.
eben> 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.
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.
for sake of argument, call the latter the ui continuation.
bemasc> right, and that's why the roll of film is the Project File for this
instance. that's why I'm suggesting that non-critical state be put in
a separate dotfile
eben> right, a hidden file, or in metadata....but yes....all state not
appropriate for the objects themselves goes elsewhere.
m_stone> Please see the picture and descriptive paragraph at the top of
http://wiki.laptop.org/go/User:Mstone/Bundle_commentary. Then, please
use the already documented terminology until you demonstrate that
this terminology is inadequate. (though please comment inline in this
page and sign your comment if you think I left out something
important).
eben> where does metadata/state live in this diagram? As "instance"?
m_stone> UI state lives in the "instance" node.
m_stone> give me some examples of metadata?
eben> well, two flavors of it: creation date, participants, tags,
description, activity specified metadata such as number of pages,
etc. Then there is state metadata for the purpose of recovering the
instance (the UI continuation part)
m_stone> 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
m_stone> so I would say that the action has a set of time periods when you
worked on it. likewise for the objects.
homunq> OK, sorry, I need to go back for a second. 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". However, I
still like version history because it is compatible with the model of
forking versions of an arbitrary object, not just of an activity. My
feeling is that the journal UI should support this forking-version
model in some way.
homunq> OK, it was good for me to say that - it made me see that they are
separate issues.
bemasc> really? I thought we were going for copy-on-write semantics.
eben> that's true in general but in practice, it's complicated. Consider a
Journal entry which is just an action "you sent file X to your friend
Y". That's an action which references X, but does not copy it. In
fact, it's not a write. But that doesn't mean that we won't have
multiple actions referring to the same object (actually, version
thereof)
bemasc> Then we shouldn't say actions=instances anymore. I would argue that
that action does not have any instance associated with it.
m_stone> depends whether the action is resumable. actions which can be resumed
have instances associated because instances are the actual material
which permits resuming
eben> which is why the graph m_stone pointed two has those three nodes in a
little triangle and why the bundle (needed for resuming) is a child
of the instance.
m_stone> 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...
bemasc> I think that makes sense, so the action should retain pointers to the
appropriate objects
Grammar and Criticism
bemasc> what we have further been proposing is that each instance refer also
to some specific object as the Main Object
m_stone> and, at face value, that sounds nuts. (though perhaps I haven't
understood your use case or your design)
bemasc> the use case is determining which activities are capable of resuming
an action
m_stone> resuming an action? perhaps you meant 'processing an object
container'?
bemasc> I'm speaking from the user's perspective
m_stone> don't. one makes a new action, the other doesn't... apologies, the
"don't" was a visceral reaction - a segment of "your statement does
not typecheck"
eben> we meant 'resuming the instance'. The question is: "which bundles,
apart from those linked to the instance within a given action, could
be used instead if desired?"
bemasc> Suppose I've just used Record to take 10 pictures. I now want to view
them in a gallery that understands Record's photoset file format. How
should we think about this?
m_stone> (perhaps because it's a standard List format used throughout
Sugar...)
bemasc> one option is to offer a number of activities that can resume this
instance
m_stone> I say: "You View the photoset."
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. (Recall that Activities are usefully regarded as
prototypes of instances)
eben> right, so we're talking about how to "find the viewer"
bemasc> the broader question is: when do we resume instances, and when do we
open files and thereby start new instances? We are trying to come up
with a way to make this determination. 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..."
m_stone> I see two formulations. I don't yet have a strong preference between
them. a) Activities can be used to synthesize instances ready to
process some objects. It's just part of what Activities are. 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...). ;). 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.
bemasc> I don't understand, as usual. Do you mean Activities can be
performed on object containers?
m_stone> I mean that the shell should understand object containers for me so
that I can Paint on individual photos from a roll of photos of
butterflies that I Recorded yesterday.
m_stone> eben: have I lost you as well?
eben> Only inasmuch as I don't know what point you're driving at with the
example.
m_stone> I'm saying 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 <---->" since
activities are logically quite similar to prototype instances in that
they offer some fixed UI continuations which can be combined with
zero or more objects. (i.e. they tend to have a default "initial UI"
that they use when instantiated.)
bemasc> nobody else here as written a program in a prototype-based language,
so please use a different metaphor
m_stone> never used javascript?
bemasc> oh, didn't know that
m_stone> here's another small example:
http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html
#Objects-Overview (for future reference.) :)
mtd> 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. given the stack = the metadata and the runtime = a
new instance of an activity.
bemasc> "resume this instance with Activity A" literally means "start
Activity A and tell it to open this object container"
m_stone> resume this "instance" with activity A? According to my grammar, you
should mean "resume this instance|".
bemasc> I do not support your grammar.
m_stone> The "with acitivity A" seems nonsensical. Instances are not
parametric over activities.
bemasc> they are if we decide they are.
m_stone> why is the resulting UI a good one?
bemasc> mostly because we have no distinction between object containers and
instances in the UI
eben> agreed with m_stone regarding "resume with" being the wrong speech
for the intended meaning of the operation. We considered "as activity
A" instead...
Manipulating Object Containers
bemasc> 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" where the abstract project is concretely
represented by an object container, not by any particular activity.
m_stone> 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".
eben> Actually, project in his meaning was "the file which describes what
to do with the useful group of objects"
m_stone> a simple collection of objects does not innately specify an activity
I can use for processing those files.
eben> That's the point of the "project file" in the first place. There
*is* something that takes on that role. (And which advertises it's
mime-type so other activities can be instantiated from the objects.)
m_stone> note: an instance is navigable to the activity that is its prototype.
that way, if I want to have another instance of recording on "fish"
instead of "butterflies", I can get there from the instance
associated with the action of recording butterflies. However, I'm not
connected solely to Record from the collection of objects. In fact,
if Record has no photoediting capabilities, I'm might not ever find
it adjacent to the photos in the UI.
eben> 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"
Website Example
bemasc> Suppose I write a webpage using the Dreamweaver activity. It's a
collection of files, with one HTML file but also CSS and jpeg's. Then
I decide that I want to view it in the Browser. then I decide that I
want to edit the CSS by hand in a text editor and then I decide I
want to open it with dreamweaver again. first: how do I open the
webpage with Browse?
m_stone> you've got tree-structured data. All of our "object containers" to
date can be represented as plain old directories.
bemasc> right, but how does the Journal know that Browse can open this object
container?
eben> I don't think that's true. the photos example is a case where the
container is empty apart from its contents.... however, 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. 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.
bemasc> but the HTML file alone will not open correctly in Browse, and this
is my key point
m_stone> I suggest you draw some labelled graphs of the progression of data
through your use case. it will be much easier to discuss specific
diagrams.
bemasc> I am much more interested in working from the user's perspective
m_stone> then draw your diagrams from the user's perspective first and
translate beneath them into the dataflow perspective. begin the
action of Browsing the Web-page.
bemasc> So which button would that be? what should a user have to do, after
having put together a webpage in a creation activity, to view it in
the Browse activity?
m_stone> I'm sorry, but text in IRC is not cutting it for me. I'm just not
understanding what you're getting at. Please provide a diagram, or
adapt my diagram and show where the fault occurs.
bemasc> I cannot diagram this
m_stone> can you write a paragraph instead?
eben> why wouldn't it open in Browse?
bemasc> because the HTML file is missing the CSS and pictures. so it might
open, but it would be missing lots of pieces.
eben> no, all that stuff is contained in the "useful objects collection" of
the instance, right?
bemasc> Browse needs to be able to open the whole "object container"
eben> Why shouldn't browse be able to reference these?
bemasc> because HTML refers to images by paths, but those pictures won't even
be visible in the filesystem to Browse
eben> Why not? If not, how are they even accessible to Dreamweaver when
you resume it!?
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?
bemasc> the difference is that in this case, that image won't even be in the
filesystem as seen from the perspective of Browse. activities can
only see the specific files that they have been told to open.
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.
bemasc> you can't modify the HTML file to include references, or it won't be
HTML. so instead, we create a "container"
bemasc> I imagine it as a .tar file containing the HTML file, the pictures,
and the CSS
eben> :-/ Then what good is this?
bemasc> if you open the .tar file with Browse, it works
bemasc> because it has all the components
bemasc> if you open just the HTML file, you get just the HTML file
eben> But the tar file doesn't have type HTML
bemasc> but it does, because we designate the HTML file as the "project file"
for this container
eben> No, if that were the project file, then that's what would open with
Browse.
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 so
the Journal offers the user the ability to open this .tar file with
Browse
eben> So you're proposing that every "collection of objects" is a tar file
instead. when the user accepts, the datastore unpacks the tarfile
into Browse's directory and then points it at the project file, which
is HTML
bemasc> not specifically; there are many other implementations
eben> You're talking the technical side. The user doesn't know this was
ever tarred. They can still see each, and interact with each object.
m_stone> he's just saying it to give your mind the flavor of the packaging-of-
related-stuff-together. The Browse-displaying-website example is
really the "interact with this html file in the context of this
larger collection of stuff"
"Act on ___ with ___"
bemasc> right, but interacting with the HTML file itself is very different
from interacting with the whole collection of files. Context is key.
eben> indeed! but, this poses some problems for the UI.... consider a
Journal entry for this instance...this HTML instance. It might read:
"Today you created This_HTML_File, which contains Image_1 and
Image_2". Now, the way to resume this directly is to click on
This_HTML_File. One would expect clicking that to resume the
instance....not open it independent of the images. What, then, if I
hover and wait for the palette to appear, to do "resume as" (or
whatever we call it)?
m_stone> eben: "act on ___ with ___"
m_stone> 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. 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 - i.e. it says "dear people looking for HTML -
start looking here; love, the Dreamweaver activity"
bemasc> if you choose to resume the action with Browse, you get all 4 files
and the webpage consists of a combination of all 4 files
m_stone> bemasc: ARGH. be grammatical. "if you choose to act on all four files
with Browse, you want to get a webpage full of pictures and CSS."
bemasc> alternatively, if you choose to act on just the HTML file with
Browse, you'll get just the text, no formatting or pictures. if you
choose to act on just the picture with Browse, you'll get just the
picture. and you can't open just-the-css with Browse, because it
doesn't support that type.
eben> back up a step. "choose to resume with Browse"... how do you do
that?
bemasc> I'm actually not sure, because I don't see any way to resume an
action in Designs/Journal
eben> My point here is, looking at the mockup, "Rain Forest" is the "roll
of film", and it is likewise the Project File
bemasc> in other words, the project file is hidden
eben> 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")
m_stone> 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)
bemasc> or one of the pictures is designated as the project file
eben> The intent was to make resuming an instance as simple as clicking on
the primary file which represents it. 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.
Hints
m_stone> that's a really bad design. you're going to want more than one of
them.
bemasc> I don't know what you're referring to. I'm just attempting to figure
out what's going on in slide 2
m_stone> I'm saying that the idea of "a single designated Primary Object" is
folly.
bemasc> it's necessary
m_stone> for two reasons. 1) because you're going to want more than one of
them. 2) because you can't guarantee that it will exist in the
presence of dumb media. 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)
eben> in dumb media, every "instance" is associated with one and only one
object. What does it mean to want more than one? Doesn't that just
imply you have two instances?
m_stone> take the web-page example. it has some html, some css, and some
photos. maybe you're lucky enough to have AwesomeEditor [etoys?] that
handles all three. however, in practice, you're likely to want to mix
and match. right?
eben> m_stone: mix and match in what sense? One could "open" any of the
objects independently.
m_stone> but some of them must be opened in context in order to make sense.
(an essay containing labelled diagrams is an easy example.) but let's
go with the web page for the moment.
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. so one object = one instance won't
work
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.
bemasc> the problem is, the UI has no way to open a collection (that I know
of)
eben> But you just got through proposing the tar approach for getting
around that internally
bemasc> sure, but I'm talking about in the UI. the only way one ever opens a
collection, in the mockups, is to "resume" an activity
Remixing Objects
eben> The only way to *use* the collection of objects is to do so from its
corresponding action entry, naturally. 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. In the
same manner, that object would be the thing which had a "resume this
instance as activity X" option in its palette. In other words, the
representation of the primary object in the design is *as* the
instance...
m_stone> eben: how do you mean? consider turning a roll of photos into a
slideshow.
bemasc> you mean a stand-in _in the UI_. I hadn't thought of that. but every
object can be opened by other activities. so one object can be opened
or resumed, and these mean different things?
eben> so there's a hole in the system, right? 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. 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)
bemasc> eben: what I want is a way for the user to open a collection.
Currently, collections are only represented, as actions, so I've been
using the word "resume" to refer to opening a collection
eben> currently, meaning in the designs we're looking at, right?
bemasc> eben: yes
m_stone> well, how does the photoroll -> slideshow example work? 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. (and, in future work, pay attention to
changes made to that collection [or to new versions of it that
appear, etc, etc])
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". The current design only really has versioning for
objects, not instances.
m_stone> don't you mean 'for objects, not _collections_'? at the big Journal
meeting w/ marco, tomeu, bertf, &co. we definitely discussed being
able to use collections as part of several actions.
eben> Ummm, I don't know? 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.
Conclusions
bemasc> it depends on what the metaphor is. let's not forget the problem of
figuring out which version of an activity can resume an instance,
which is how this conversation started.
m_stone> (a problem with at least one easy solution, namely, to regard
instances as executables derived from some prototype...)
eben> I feel like we've gotten about nowhere in an hour.
m_stone> 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.
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.
bemasc> (I thought you guys already _had_ this meeting, 7 months ago)
eben> We did. It resulted in the mockups you see. Which still aren't
perfect!
m_stone> they don't need to be perfect. they've already allowed significant
progress. they're mockups for a reason! :)
m_stone> we also have the "make website - view website - edit images - edit
html - view website" sequence. 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.
eben> right, both of those use cases are not covered, at present, by the
design. Mostly because we don't have aliases/references in that sense
at all.
m_stone> so we should explain that clearly on the design and send some email
so the rest of the world can think about it.
eben> certainly, that's my point, and why I think it's worth another
meeting to make them better. 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? 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.
bemasc> eben: I think I get it. Interesting... 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
m_stone> eben: I didn't quite follow that comment and I need to relocate to
1cc anyway. sounds like it's worthing reflecting on though.
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?
homunq> OK I'm back. Just so you know, I think it was a very productive
conversation. I definitely think that forking versions in the journal
is something out-of-scope but worthwhile. but in-scope, I now see
what is needed for activity bundles. The html problem (html stores
references as paths) is I think soluble - every "open this" is either
alone or in a symlinked directory of the bundle. internally, I think
the files would be separate - not a tar -but there would be a way for
sugar to create a tar to share with others. in fact, I think it would
create a tgz. Honestly, this whole idea is just a few steps short of
turning activity bundles into actions rather than objects. The
MANIFEST could be the "master file". one missing part would be, where
do you keep the private signing key. I think that if you edit the
html, the UI continuation will be out-of-date.
eben> This issue of "editing subparts with other activities" was never
formally discussed, and currently has no solution. I'm not sure what
to do with that.
m_stone> first, write that it exists. Then, spend a few days thinking about
it. It may turn out to be nothing more than "future work".
eben> I've thought about it at length, without coming to any meaningful
conclusions.
m_stone> don't give up. you'll work it out. (with help from many others, I'm
sure)
eben> It's a complement to the problem of "embedding an image in a Write
document, editing that image in Paint, and later updating the version
in Write automatically". And it also boils down to the copy-on-write
vs. reference debate.
