On Thu, Oct 9, 2008 at 6:55 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: > On Thu, Oct 09, 2008 at 12:13:02PM -0400, Eben Eliason wrote: >> On Thu, Oct 9, 2008 at 10:15 AM, Carlos Nazareno <[EMAIL PROTECTED]> wrote: >> > Hi Tomeu. Some personal feedback: >> > >> >> 3) Basically - The journal is really hard for people/ kids to use over >> >> a longer period of time. Kids and teachers can't find things that they >> >> did unless it was done within the last 30 minutes. >> >>Could you please elaborate on the difficulties that people have when >> >>using the journal? >> > >> > I've experienced the same problem. Items tend to clutter up in the >> > journal over time, it's like viewing your entire web browsing history. >> > Its current implementation simply leads to information overload with >> > the accumulating number of entries. >> > >> > IMHO, the philosophy of "nothing gets forgotten" with the journal is a >> > bit flawed because as people we don't even naturally do that. We >> > selectively choose which information to remember and mark as important >> > and discard the rest because that's just information overload. >> >> You're right on with this comment. Of course, I don't think "nothing >> gets forgotten" is really what we're aiming for; in fact, we aim for >> much the opposite. However, as it's currently implemented, you're >> right! The Journal is actually supposed to retain everything you've >> done *quite recently* so that you can always go back and find, remix, >> resume, etc. Experimentation is encouraged. >> >> However, the very principles the Journal was designed around include >> the concept of memory, and particularly the fading thereof. Over >> time, less used, unstarred, unimportant files will eventually be >> backed up and then removed (probably after confirmation, but perhaps >> you can opt out of the confirmation step) by the system, so that the >> further back in time you look, the less you have left, but the more >> relevant the remaining items are to your history with the laptop. >> >> This is a very important aspect of the Journal that just hasn't had >> time to happen, yet. >> > > You acknowledge that the system is not functioning as well as it should > be in its curren state. Please stop saying "we are going to do this" > and look for the simplest way to achieve a usable system for our usesr. > I will gladly help in this endeavor, but I am concerned by our security > system and the frequent implications that we are holding to old designs > that my ideas and motivation have no place in this effort.
No idea about what security has to do here. The journal development has stalled because a fundamental part of it (the datastore) hasn't had resources assigned to it. Don't ask me why. You're continually mixing implementation and design issues, which makes this discussion much more difficult than it already is. I don't think there's much interest in discussing that the current implementation sucks, we all agree here. What we would like to discuss and would welcome your contributions, is how the design can be improved in such a way that a much better implementation can happen soonish. Several people are contributing usefully to this discussion, why do you think you are not able to? > I don't think we can incorporate the concept of memory and forgetting > into the Journal in a programmatic way. Forgetting is as much a learned > skill as remembering, and attempting to replicate it in software seems > like a very difficult, if impossible, task. I feel that we are tilting > at windmills if we believe we can reliably produce something so > incredible in any conceivable timeframe. I don't think we aim to actually replicate any brain function. We "just" want to give the user tools that assist him in better managing his data in a space with restricted capacity. > I positively advocate a simplification of our expectations about what > the Journal will do. Just a system which consistently suggests (but > does not enforce) default, intelligent organizations for things in a > traditional filesystem, provides manual and automatic tagging support, > and indexes the text of written documents will be a giant step forward > in terms of reliability and interoperability with the outside world. > With metadata about files stashed in a database, such as time, date, > text (for indexing and search), tags, creating application, etc. we can > do everything the Journal is intended to do, but no sacrifice the > simplicity and reliability of the default filesystem in the process of > developing the Journal to its full capacity. > > For this we only need to work on three sets of components: > > 1) Journal -- a file browsing application which provides numerous views > onto the corpus of data the user creates and handles; views being > time-ordered, filtered, hierarchical (traditional), tag-based, etc. > Allowing other applications to manage files will let contributors create > or port existing systems to the Sugar environment to fulfill these > functions as well. > > 2) Indexer -- a simple filesystem crawler that walks across the set of > directories to which users are expected to save data (e.g. not Activity > directories or hidden directories in /home) and executes plugin scripts > which produce indexable metadata and fulltext for use in later searches > by the user. The scripts can have a standard IO format, such as used by > tracker, and can be installable by inclusion in Activity bundles. > > 3) Watcher -- a filesystem watcher which uses inotify to watch for > changes in the set of directories to which the student writes data. On > change, invokes the indexer, which then executes the corresponding > metadata / fulltext extraction scripts and adds the file in question to > the index accessible and searchable by the Journal. > > I feel that we are moving in this direction, but to really get there so > much has to change in the architecture of Sugar that I am afraid that > this work will be unsupported and renegade in flavor. I'm really surprised now. You are saying that you cannot fruitfully participate in discussions about the journal future, but at the same time you have just described a design that most people around here would broadly agree with. What support do you expect from us, that we summon a couple hundreds of fairies and put them to work on the journal? > I am furthermore frustrated by the tight integration of the Journal into > the window manager. I don't know if this is funny or depressing. Please glimpse through the journal code (it's not big) and tell me where it has any dependency on the window manager. Don't worry looking for dependencies on Journal in the window manager itself, because we run an unmodified Matchbox. I'd like to know why do you feel the need to make such crazy assertions, I don't think this helps in any way. > In particular, our security model has the effect of > preventing work on this issue that isn't supported by all the core > developers. Again, I don't see what security has to do with all this. > We can only have one file management application. Can you elaborate? We'd prefer for our users to have just a simple way to manage their data, but if you think that the Sugar design should make easier for people to plug-in different journals, etc., then you can propose changes and send patches. Actually, Marco has done work recently in that direction. Must be because he's coding that he doesn't write that many emails, maybe I should do the same... > I am > afraid that I or another interested developer will implement such > systems but find they are rejected by the core developers, and it will > be impossible even for users desire to use them to easily do so. Several people have found ways to contribute their work to Sugar. Why do you fear that you won't be able to? It's not that we don't have our own views on what is best nor that we let people change everything as they like, but we welcome any help we can get and are ready to make lots of compromises to get it. Regards, Tomeu _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
