<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">The idea is to have the notion of container entries that can contain<br>other journal entries.</blockquote>
<div><br class="webkit-block-placeholder"></div><div>This does get tricky fast. I think we'll need to discuss it briefly at our design charrette on Tuesday. There are certainly many cases where we could use it, but I think a flat system where each entry is exposed individually could still work. I could be wrong; We'll have to try it to know how it scales.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">A Record entry would contain several entries, one for each photograph or<br>video taken during that session.
<br><br>Resuming the container entry would open Record with that session<br>resumed.<br><br>Resuming any of the contained entries would resume Paint or another<br>activity that registered for resuming that mime type.</blockquote>
<div><br class="webkit-block-placeholder"></div><div> </div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Also, individual entries as well as containers could be copied or
<br>dragged to the clipboard.<br><br>Looks like in the case of etoys, if during the activity session were<br>created more than one project, etoys could create a container session in<br>the journal that contains one entry for each project.
<br><br>The container entry as well as the individual projects could be resumed<br>by etoys.</blockquote><div><br class="webkit-block-placeholder"></div><div>I want to briefly ignore the technical point of "container" entries vs. "a bunch of entries created by one activity instance" and talk about the broader concept of sessions. From my perspective, it makes sense to treat each photograph as a separate entity in the Journal, apart from the meta entry, the "roll of film." On the other hand, I do not feel that this can be said for Etoys.
</div><div><br class="webkit-block-placeholder"></div><div>For on thing, Etoys refers to things as projects, which already sound like self contained bundles of sorts, much like a "sessions" in their own right. Combining several projects in one session just complicates matters, when each can clearly be stored as its own entry within the Journal and resumed at will. This is, after all, the basic model we're after. But when, then, is it OK or even essential to break it?
</div><div><br class="webkit-block-placeholder"></div><div>I've been trying to come up with the rules which govern why I feel so strongly about the difference between these types of activities, and it's not an easy task. That, and my lack of time to concentrate any time on the HIG lately are part of the problem here, regardless of the API, and I apologize. Still, Ill try to make a stab at it here, in hopes that you can all punch holes in my attempt.
</div><div><br class="webkit-block-placeholder"></div><div>I think there are two aspects which relate to my feeling on the matter. First, the camera activity is -- forgive the pun -- a one shot activity. That is, the act of taking a single photo is immediate, and once that photo is taken, it cannot be altered from within the activity itself. It's a constant from its time of creation, and its existence within the activity session is a boolean value. The core point here is that the object is not the subject of continual modification; It does not have versions. In a space like Etoys provides, each project can be opened, modified, and resaved at any time...each project has its own history. In the photo activity, on the other hand, the series of photos is the history of the roll of film, so to speak. This doesn't mean that you can't edit a single photo...you certainly can, but not within the Camera activity, which is designed solely for capturing the images.
</div><div><br class="webkit-block-placeholder"></div><div>That brings me to my second point, which is that some "primitive" types (and probably some non-primitives as well) are naturally suited to being available to a number of different activities. I could draw on top of a photo I took; I could place it within a paper I'm writing; Etc. I mostly see this with media types, but I don't want to assume there aren't other cases. When a subcomponent of a session can be individually treated as its own object *and opened within other activities* then I see it as something that could deserve its own journal entry, separate from the session entry itself.
</div><div><br class="webkit-block-placeholder"></div><div>As another example, consider the difference between these two sound activities: Record and SoundMix. Both let you record sounds from the mic. Record is basically an audio capture device, of sorts; It records sounds. SoundMix does this also, but provides a timeline and tools for adjusting the pitch, cutting, splicing, phase shifting, and filtering; It's a sound editor. Sounds captured in Record could be treated as separate entities. They could, naturally, be imported into SoundMix. The sounds recorded within SoundMix, on the other hand, are created for the purpose of being chopped/mixed, and are part of a larger project that can be continually edited, and so a SoundMIx project really only needs to create a single entry.
</div><div><br class="webkit-block-placeholder"></div><div>I hope that sheds a little bit of light on the whole idea. I'd welcome any comments or arguments on the matter. Obviously its a tricky problem, and one that developers are closer to than me. Your feedback is the only way we'll create a robust system. Thanks.
</div><div><br class="webkit-block-placeholder"></div><div>- Eben</div></div>