<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I haven't used the ds_backup.py as released, but AFIK rsync uses the
    -d flag which deletes objects from the backup if they have been
    deleted in the Journal.<br>
    While it does make multiple snapshots, AFIK, the restore mechanism
    does not support using them for versioning. I don't believe there
    are any changes in the XSCE implementation form XS-6.<br>
    <br>
    Tony <br>
    <br>
    <div class="moz-cite-prefix">On 02/22/2016 07:56 AM, Samuel
      Greenfeld wrote:<br>
    </div>
    <blockquote
cite="mid:CA+cAqjO5AHDX8HQYMnR5dSfoUhZCLoSXm5zbJL0WRs67zmRYmw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>Just for the record:<br>
              <br>
            </div>
            The XO laptop backup mechanism for Sugar creates separate
            "datastore-YYYY-MM-DD_HH:MM" directories for each backup.<br>
            <br>
          </div>
          <div>If I recall correctly, the schoolserver also periodically
            looks through these backups, hardlinks identical items to
            save space, and prunes backups beyond a set age.<br>
          </div>
          <div><br>
          </div>
          I wouldn't be against fixing and/or redesigning XO backup
          & restore, but at least on an XS schoolserver these
          already are versioned.<br>
          <br>
        </div>
        I have not tried XSCE to see how it handles things.<br>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sat, Feb 20, 2016 at 9:40 PM, Tony
          Anderson <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000"> Hi, Sam <br>
              <br>
              Thanks for your comments. These issues need review and
              comment within the community.<span class=""><br>
                <br>
                <div>"Just my 2c, but this complicates the experience a
                  lot.  Do we show this temp journal entry to the user? 
                  If so, wouldn't that be confusing?  But it we hide it,
                  it becomes more complex.  Eg, a user is adding the
                  finishing touches to a diagram in Paint, and adds it
                  to Write activity, however since only the old version
                  is visible they don't see the image they expected, and
                  become confused.  Maybe this could be better served by
                  basic git features in the journal, one of Martin's
                  project ideas I believe."<br>
                </div>
              </span>
              <div> <br>
                What I suggest does not change the user's experience of
                the Journal. <br>
                <br>
                When an activity is launched, it runs as activity.py. If
                an activity is resumed (associated with a data file in
                the Journal), activity.py loads that Journal object.
                This is the object that is saved when the activity
                terminates. What I am suggesting is that <br>
                activity.py should load a copy of the Journal object
                (which naturally does not exist in the Journal until
                saved). This enables the activity to make a decision to
                <br>
                overwrite the original object or to save a new object. <br>
                <br>
                You may have noticed this in the Journal. When you
                resume and then save, that object is now the most recent
                and no longer appears in its original chronological
                position. This reflects that the original journal object
                is saved back to the Journal (normally, by write_file)<br>
                <br>
                The scenario you describe: using Paint and then saving
                to Write is intermediated by the Journal. Paint saves
                the modified image to the Journal. The Write activity
                then adds it to its document. There should be no
                confusion. Assuming the user gave the image a new name,
                causing a new object to be saved or the user saved in
                the same name, replacing the object in the Journal. If
                the user has doubt, as at present, he/she should run
                Image Viewer to see the image.<br>
                <br>
                I really don't see git as relevant to the Journal. The
                proven technique of using file names to distinguish
                objects is easier to implement and familiar to
                experienced computer users. There is nothing to prevent
                a user from using classproject.1, classproject.2, ....
                to distinguish versions.<span class=""><br>
                  <br>
                  "Browse save files work fine cross network
                  connections.  I made one at home, and opening it at
                  school I was able to show people all of my tabs."<br>
                  <br>
                </span> This worked because in both cases you are
                connected to the internet. Browse is saving urls. Had
                you opened Browse without a connection, you would have
                received an error. In last year's GSOC, Richa Sehgal
                added a capability to save an html page explicitly but
                this capability has not yet been integrated with Browse.<br>
              </div>
              <span class=""> <br>
                "Using the metadata is also much harder, it is so easy
                to just chuck the json in there.  Even if we use
                metadata for eg, saving memorize, the metadata will be
                so activity specific that it is hard to use in a
                reflection tool.  I'm not sure what you want by this."<br>
                <br>
              </span> I am trying to distinguish saving documents from
              saving state. Memorize needs to save state so that a user
              can resume a game. Naturally, state information is
              specific to the activity. However, it can be saved in the
              metadata record (saved in the Journal as a file). When
              resumed, Memorize can restore its state. Saving the state
              information as a document requires that it have a
              mime_type. This type would need to be unique to Memorize
              since no other activity would know how to process it (e.g.
              if it were saved as application/plain-text).<br>
              <br>
              As I understand reflection, the goal is to enable a user
              to look back at documents they created or worked on
              collaboratively. The Journal offers two impediments to
              that - clutter from non document-creating activities and
              the necessity to erase documents due to limited storage
              capacity. I think we need to distinguish between
              statistical analysis of a user's activities (the NSA use
              of metadata) and using the Journal to show the user a
              record of their own educational journey.<span class=""><br>
                <br>
                <div><br>
                </div>
                "I have to agree with you here.  Having a kind of
                seamless journal that exists partially locally and fully
                on the school server would be nice.  But can a person
                designing this amuse that the user will have school
                server access most of the time?"<br>
                <br>
              </span> The design is to invoke a backup service when the
              XO connects to the school server. This service recognizes
              objects which have been modified or which are new and
              saves the associated documents to the server-based store.
              Currently, I use a modified ds_backup.py to save to the
              /users directory on the school server (by serial number of
              the XO). This program operates using datastore as the
              input. The suggestion of using OwnCloud would make the
              files on the school server visible to the student. <br>
              <span class=""> <br>
                "How do you it fulfilling that need?  Are we exposing
                the owncloud web interface to children?  I pictured a
                seemless journal interface that merged the online
                storage and the local into one and provided means for
                pinning things locally.  I however picture the group
                task creating a new type of voulme (or web service) that
                allows for seemless sharing, not aiming to provide
                backup."<br>
                <br>
              </span> These are exactly the issues we should tackle as a
              community in the Sugar-devel design process. OwnCloud is a
              part of current releases of XSCE. Its interface is
              controlled by administrator configuration. TK has used
              OwnCloud with children in Malaysia. From the user's
              perspective, the OwnCloud interface is a link (login) on
              the school server.<br>
              <br>
              Currently, I am using the 'keep' circle for this purpose.
              When it is filled, it means a copy of the file is stored
              locally. The user can 'fill' the keep icon to request that
              a local copy be made (the next time the backup is
              executed). The user can clear the keep icon to show that
              the backup process can delete the local copy. <br>
              If the user 'erases' the Journal object, the backup
              process will delete the school server side copy. <br>
              <br>
              I don't know how sharing can be done seamlessly. The user
              needs to 'share' an object. Another user has to perform
              some action to add the object to his/her Journal. The user
              needs positive control over this process to manage limited
              storage. <br>
              <span class=""> <br>
                "Ah, hating on the home view ux is fun.  I was actually
                thinking about this a while ago, and wrote a blog post. 
                I'd like to hear your thoughts as it addresses the same
                issue:  <a moz-do-not-send="true"
                  href="https://www.sam.today/blog/sugar-nohomeview-design.html"
                  target="_blank">https://www.sam.today/blog/sugar-nohomeview-design.html</a>"<br>
                <br>
              </span> I hate unity on Ubuntu with an abiding passion.
              The home view is the face of Sugar. The problem with the
              home view is exactly what you point out in your <br>
              design document - it now confuses the functions of the
              Journal with the function of the Home View (and List
              View). This happened when an effort to make more use of
              the Journal resulted in making the default of the Home
              View to restart the latest execution of an activity. This
              confuses the activity with the task. When I launch the
              Write activity, I may want to continue editing an existing
              document or I may want to create a new one. <br>
              <br>
              I don't know of any desktop implementation that merges
              these two functions. If I own Word, I get a new document
              with the option to open an existing document. If I launch
              from a file explorer, Word opens that document for
              editing. This was the case with Sugar. If an activity was
              launched from the Home View, a new document was created.
              If the user launched from the Journal (Sugar's file
              explorer), that file was opened. <br>
              <br>
              I am only proposing that the default in the Home View
              return to starting new by default. The alt key can then be
              used by those who want to resume from the Home View (most
              of whom will click on the Journal button and resume from
              there).<br>
              <br>
              We should require documents to be stored under a user
              supplied name but much as in most other desktops, this
              decision should be required when the document is saved,
              not when the activity is opened. In some releases, there
              was an 'alert' when an activity was closed. Unfortunately
              this alert did not solicit a name, but a description of
              the file. It's implementation was a bit aggressive and so
              it was subsequently deleted. In the original Sugar, the
              user was expected to change the name in the Journal by
              changing the entry in the standard toolbar. In the new
              toolbar design this field is invisible to the user unless
              they click on the activity icon. Changing the name here
              should change the name in the Journal. However, with the
              current implementation, this is too late. The name change
              applies to the object that was opened so that it does not
              have the 'save as' ability to create a new document. <br>
              <span class=""> <br>
                "I will actually be persuing that feature, and the steps
                defined on that page as a feature for 0.110.  Eventually
                it will have a feature page, but it is the "onboard"
                branch of <a moz-do-not-send="true"
href="https://github.com/samdroid-apps/%7Bsugar,sugar-artwork,sugar-toolkit-gtk3"
                  target="_blank">https://github.com/samdroid-apps/{sugar,sugar-artwork,sugar-toolkit-gtk3</a>}. 

                I invite you to test the patches and provide feedback."<br>
                <br>
              </span> Your idea here is brilliant and addresses a
              continuing problem in the OLPC concept. One of the most
              insistent and persistent criticisms of OLPC has been <br>
              the inadequate training of the teachers in a deployment
              and their inability to use the XO effectively. Much of
              this results from the practice of having knowledgeable
              people from the the gifted side of the digital divide go
              to the challenged side to give an introductory workshop
              (onboarding). Often the <br>
              participants have no 'hard-copy' of the training materials
              and so soon forget details of the training or run into
              situations not covered. <br>
              <br>
              I would like the implementation to be 'interpretive' in
              nature so specific deployments and members of the
              community can devise their own scripts. As you have
              pointed out, you are assuming a user who is experienced
              with standard computers and their conventions. This is not
              the situation in our deployments in the challenged
              environments. <br>
              <br>
              Your scripts indicate a limited set of actions (define a
              'hotspot', display a window based on cursor position, take
              a subsequent action based on an event). While it will be
              extra work, if you analyze the actions in your design
              document, you may find that they could be defined by a
              small number of parameters (and links to popups). These
              could then be documented in a script and executed by a
              'onboarding' engine. <br>
              <span class=""> <br>
                "Sugarizer has a different collab model (some js thing)
                to the rest of Sugar.  However, SoaS and XO are both
                running the same Sugar, with the same collab model
                powered by Telepathy.  I have use their collaboration
                before."<br>
                <br>
              </span> Sadly, I don't know enough about the technical
              issues. In Walter's context, we need a collaboration model
              for javascript activities (Sugar-web-activity). This
              collaboration model should work also for Sugarizer (As I
              understand it, Walter and Lionel have a goal that any
              Sugar-web-activity also works in Sugarizer).<br>
              Since collab-wrapper is a layer between the underlying
              technologies and the user, it would be very valuable if
              that same 'api' would work in both the Python and the
              Javascript environments. <br>
              <span class="HOEnZb"><font color="#888888"> <br>
                  Tony</font></span>
              <div>
                <div class="h5"><br>
                  <br>
                  <div>On 02/21/2016 05:00 AM, Sam P. wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr"><br>
                      <br>
                      <div class="gmail_quote">
                        <div dir="ltr">On Sat, Feb 20, 2016 at 6:00 PM
                          Tony Anderson <<a moz-do-not-send="true"
                            href="mailto:tony_anderson@usa.net"
                            target="_blank">tony_anderson@usa.net</a>>

                          wrote:<br>
                        </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000"> Hi,
                            Walter<br>
                            <br>
                            I have some concerns about the proposed GSOC
                            tasks as well as some ideas for new tasks.<br>
                            <br>
                            I agree that the Journal needs rethinking.
                            Below are my thoughts (re-thoughts?).<br>
                            <br>
                            Specifically,<br>
                            <br>
                            The Journal is the file system for Sugar. It
                            does not use directories but instead was
                            intended to collect objects by tag (a la
                            Picasa). Currently, the user sees <br>
                            a scrolled list of objects in chronological
                            order. However, selection is by activity or
                            media type, not by a user defined criteria
                            (as represented in other systems by the
                            directory). <br>
                            <br>
                            The Journal acts as an activity with awkward
                            consequences for the user. On the keyboard,
                            the icon for the Journal (a magnifying glass
                            or search icon - not the icon shown in the
                            frame) is to the left of the zoom group on
                            the keyboard and to the right on the frame.
                            If the Journal is selected, it replaces the
                            current activity when the activity key is
                            pressed. It also appears as an activity when
                            using alt-tab. The first makes using
                            screenshots awkward. Screenshots are given a
                            title by the system of 'Screenshot of ....'.
                            The user needs to switch to the Journal to
                            provide a meaningful name. However, the user
                            must open the frame and click on the
                            activity icon to return to it. If the
                            Journal were viewed as a Sugar service, the
                            activity key would return the user to make
                            another screen shot or continue whatever the
                            task is. Similarly, it is convenient to
                            present the user with instructions to
                            perform a task using a Sugar activity (e.g.
                            Write). The instructions can be given by a
                            web page or by a document in a different
                            activity. For example, a user could show a
                            flag as an image in Image Viewer and try to
                            duplicate the flag with TurtleBlocks.
                            However, using alt-tab to switch between the
                            activities requires cycling through the
                            irrelevant Journal activity or open the
                            frame to click on the activity icon.<br>
                            <br>
                            More importantly, when a Journal object is
                            launched from the Journal activity, it is
                            immediately loaded into activity.py.
                            Therefore, any subsequent action by the user
                            will be saved and the previous object will
                            be overwritten. Suppose I resume the Paint
                            Activity to continue making a picture.
                            However, I decide that after some strokes,
                            the original picture was better. There is
                            nothing as a user I can do to revert to the
                            original. I suspect the reference to git may
                            be intended to address this problem. When an
                            object is launched, activity.py should make
                            a clone. The user should then have the
                            option to revert to the original or to
                            overwrite it or to change it's name so that
                            a new object is created alongside the
                            original. I believe an implementation of the
                            'save/save as' logic of virtually all other
                            systems should be provided.<br>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>Just my 2c, but this complicates the
                          experience a lot.  Do we show this temp
                          journal entry to the user?  If so, wouldn't
                          that be confusing?  But it we hide it, it
                          becomes more complex.  Eg, a user is adding
                          the finishing touches to a diagram in Paint,
                          and adds it to Write activity, however since
                          only the old version is visible they don't see
                          the image they expected, and become confused. 
                          Maybe this could be better served by basic git
                          features in the journal, one of Martin's
                          project ideas I believe.<br>
                        </div>
                        <div> </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000"> <br>
                            Probably, in the interests of 'reflection'
                            or possibly statistical data, the Journal
                            saves every activity instance - by default
                            with the name of the activity. Further, <br>
                            most activities now implement write_file to
                            create a data file associated with the
                            object. This creates clutter in the Journal
                            and takes storage for meaningless data
                            files. For example, the Browse activity
                            saves a data file containing URLs of open
                            tabs. Aside from the fact that this creates
                            spurious error messages if Browse is opened
                            in a different network environment, it
                            creates the unnecessary need to save a data
                            file. I believe that activities should only
                            save a data file if the user supplies a name
                            for it and that activities should save state
                            in the metadata, not in a data file.
                            Naturally, it may be desirable for Memorize
                            to save its state so the user can resume the
                            game - this can be done by a field in the
                            metadata. However, when the Paint Activity
                            saves a file, it is reasonable to assume it
                            contains an image (usable, for example, by
                            the Image Viewer).<br>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>Browse save files work fine cross network
                          connections.  I made one at home, and opening
                          it at school I was able to show people all of
                          my tabs.<br>
                          <br>
                        </div>
                        <div>Using the metadata is also much harder, it
                          is so easy to just chuck the json in there. 
                          Even if we use metadata for eg, saving
                          memorize, the metadata will be so activity
                          specific that it is hard to use in a
                          reflection tool.  I'm not sure what you want
                          by this.<br>
                        </div>
                        <div> </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000"> <br>
                            The XO has limited storage capacity. A
                            freshly installed XO-1 image leaves about
                            300MB free space. A freshly installed image
                            on other models with 4GB capacity leaves
                            1.9GB free space. Today, it is almost
                            impossible to buy a USB stick with 2GB
                            storage or less. When the available storage
                            is less than 50MB, the user sees a modal
                            dialog saying the Journal is full with the
                            only option to look at the Journal. The
                            Journal activity shows the amount of
                            available storage which could help a user
                            avoid going below the 50MB limit but is no
                            help to correct the problem. Currently Sugar
                            provides no help to the user in dealing with
                            this problem. Most deployments I am familiar
                            with reflash the laptop when this happens.
                            So much for reflection. Essentially this
                            step erases the user's prior work.<br>
                            <br>
                            Journal backup, according to James Cameron,
                            is beyond the scope of Sugar. The present
                            Sugar-independent (?!?) scheme was developed
                            by Martin Langhoff using rsync to create
                            snapshots on the school server. This was a
                            bad decision. If a user deletes an object
                            from the Joural on the XO to create space,
                            that object is deleted from the backup. The
                            backup should be considered the actual
                            repository of Journal entries with
                            effectively unlimited space and the backup
                            on the XO should upload new and modified
                            objects to that repository. Further the user
                            should have a way to recall data files from
                            the repository as needed. In general, the
                            limited storage on the XO should be viewed
                            as a cache of the users' data kept on the
                            school server.  Consider that OLPC
                            recommends a minimum of 2GB storage on the
                            school server (/library/users) per
                            registered laptop. However, at most, the
                            user has 1.9GB on the XO (which includes
                            optional Sugar activities and optional media
                            and e-book downloads).<br>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I have to agree with you here.  Having a
                          kind of seamless journal that exists partially
                          locally and fully on the school server would
                          be nice.  But can a person designing this
                          amuse that the user will have school server
                          access most of the time?<br>
                        </div>
                        <div> </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000"> <br>
                            The proposed GSOC tasks include statements
                            such as: "This idea needs more thought and
                            coding." I believe SugarLabs is responsible
                            for doing the thought and proposing the
                            guidelines for implementation. This is not
                            an appropriate task for a GSOC participant.
                            One of the obvious problems as a Mentor in
                            last years GSOC is that the participants had
                            no experience with or understanding of Sugar
                            or how it works on an XO. The development
                            environment gives the developer many
                            capabilities not available on an XO (fast
                            gpu, large memory, effectively unlimited
                            storage, 24/7 high speed (> 1MB/s) access
                            to the internet, 1080p screen resolution and
                            aspect ratio). Further, Sugar on the
                            development environment is not available on
                            the XO (and vice versa). Asking participants
                            from this environment to design ui for users
                            on the other side of the digital divide
                            requires an unreasonable expectation of
                            their ability to empathize.<br>
                            <br>
                            I would propose these tasks more as follows:<br>
                            <br>
                            <dl>
                              <dt>1. Brief explanation</dt>
                            </dl>
                            <dl>
                              <dd> The Sugar Journal should provide a
                                'save/save as' interface which should
                                enable a user to choose whether to save
                                the current document when an activity is
                                closed. The interface should require a
                                name change from 'current.activity' to a
                                user supplied name. If the document is
                                derived from one currently saved in the
                                Journal, the user should be allowed to
                                save (overwrite) or save as (create new
                                document) by giving a new name to the
                                document. This could be accomplished by
                                showing a modal dialog at close time
                                requesting the user to supply a name or
                                not save the document. If the document
                                has a user supplied name, the dialog
                                could request the user to save or to
                                provide a new name to create a new
                                document. <br>
                              </dd>
                              <dd>Note: this approach satisfies the
                                needs referenced in the git task. Git is
                                a little like a hammer looking for a
                                nail. Using git for this function will
                                likely double the size of the data
                                stored in the Journal (based on normal
                                experience using git). Unfortunately, we
                                don't have this space on the XOs. The
                                standard <br>
                              </dd>
                              <dt>save/save as gives the user the
                                ability to manage versions by using
                                unique names.<br>
                              </dt>
                            </dl>
                            <p>2. Brief explanation<br>
                                      The Journal activity is currently
                              implemented as an activity. It should be
                              changed to a 'service'. This means the
                              Journal icon on the frame should be to the
                              left of the zoom group icons to match the
                              sequence on the keyboard. The Journal is
                              always running as a service when the Sugar
                              is running. It is accessible by the
                              Journal key on the keyboard and also by
                              the Journal button in the frame. When the
                              view is switched to the Journal, clicking
                              on the activity view (right most key of
                              the zoom group) should switch the screen
                              back to the current activity.<br>
                            </p>
                            <p>3. Brief explanation<br>
                                      Sugar provides a method to backup
                              and restore the Journal (one method to a
                              USB key and one method to the school
                              server). The Journal also provides a
                              select box to enable an action to be taken
                              for all selected objects. This mechanism
                              should be sufficient for the USB key case.
                              However, the school server backup
                              currently is based on taking a snapshot of
                              the current Journal state. This means the
                              size of the objects in a user's Journal
                              cannot exceed the available local store on
                              an XO (300MB for an XO-1, 1.9GB for other
                              models). A mechanism is needed to save on
                              the school server all documents created by
                              the user and to restore a selected object
                              to the Journal from the school server.
                              Since many documents may represent library
                              objects (e-books, audio, image or video
                              media), the mechanism should recognize
                              these and not save them as user documents.
                              However, the metadata saved should enable
                              the system to download the library items
                              again as needed (and, as available). <br>
                                  For example, the mechanism may be to
                              upload Journal documents to an OwnCloud
                              repository. The user could then select an
                              item in the OwnCloud repository to be
                              downloaded to the Journal. The user could
                              also share any item in OwnCloud with other
                              user groups or individuals. <br>
                            </p>
                            <p>Note: This would essentially accomplish
                              the intent of the group/buddy task.
                              Further, OwnCloud could be provided on a
                              school server or on the internet. as
                              appropriate.<br>
                            </p>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>How do you it fulfilling that need?  Are we
                          exposing the owncloud web interface to
                          children?  I pictured a seemless journal
                          interface that merged the online storage and
                          the local into one and provided means for
                          pinning things locally.  I however picture the
                          group task creating a new type of voulme (or
                          web service) that allows for seemless sharing,
                          not aiming to provide backup. <br>
                        </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000">
                            <p> </p>
                            <p>4. Brief explanation<br>
                                  One goal of Sugar is to record
                              information about user sessions. This is
                              currently accomplished by creating
                              statistics from the metadata stored in the
                              Journal.<br>
                              Unfortunately, a consequence is that the
                              Journal view fills with essentially
                              meaningless links to this metadata (mine
                              fills with Terminal Activity and Log
                              entries).<br>
                              This makes it much harder for the user to
                              identify meaningful Journal objects
                              (documents, images, items from the
                              library, ...). A mechanism is needed to
                              that session data can be logged
                              independently of the Journal view (i.e not
                              shown on the screen). This logged
                              information should be transferred to a
                              backup repository (e.g. school server or
                              usb drive) as soon as possible and deleted
                              from the local store to free up space. The
                              available reporting activities should be
                              modified to use this new mechanism.</p>
                            <p>5. Brief explanation<br>
                                  The Journal icon provides information
                              the amount of free space in the user's
                              store. if this amount is less than 50MB, a
                              dialog is shown requiring the user to
                              switch to the Journal view and claiming
                              that the 'Journal is Full'. This message
                              is, at best, misleading. The available
                              storage can arise from several causes -
                              the fact that an activities 'instance'
                              store was not deleted, the space required
                              by installed activities, or space required
                              by data files in /home/olpc/Library, or
                              data stored by activities in 'data',
                              'instance' or 'temp'. Currently, Sugar
                              provides no guidance or help to enable a
                              user to deal with this problem short of
                              reflashing the image. The goal of this
                              task is to provide a quota management
                              system on storage with a way for the user
                              (e.g. by a special Sugar activity) to
                              analyze the usage of storage and to save
                              by usb key or school server or cloud
                              storage large or currently unneeded items
                              and then delete them. The system should
                              show the user the size of items and
                              provide updates on how much storage has
                              been made free by his/her actions.<br>
                            </p>
                            <p>6. Brief explanation<br>
                                  In Sugar's Home View, a click on an
                              activity icon by default resumes the most
                              recent instance of the activity. This
                              capability is designed into the Journal
                              and is redundant in the Home View. A Sugar
                              activity is a tool to enable the user to
                              accomplish some task. If that task is not
                              completed, the user can resume it via the
                              Journal. If the tool is to be used on a
                              new task, the user can launch it from the
                              Home View. The current Home View assumes
                              that the intent of the user is to continue
                              the most recent task with that tool. </p>
                            <p>This task should set the Home View
                              default to launch a new instance of the
                              activity. The Alt key should be set to
                              enable resuming a selected instance of the
                              activity.  By serendipity, this also shows
                              the Home View with black and white icons.
                              Icons with color signifying a resumable
                              instance use the colors associated with
                              the laptop. Unfortunately many of these
                              color combinations make the icon much more
                              difficult to distinguish than the black
                              and white version. <br>
                            </p>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>Ah, hating on the home view ux is fun.  I
                          was actually thinking about this a while ago,
                          and wrote a blog post.  I'd like to hear your
                          thoughts as it addresses the same issue:  <a
                            moz-do-not-send="true"
                            href="https://www.sam.today/blog/sugar-nohomeview-design.html"
                            target="_blank"><a class="moz-txt-link-freetext" href="https://www.sam.today/blog/sugar-nohomeview-design.html">https://www.sam.today/blog/sugar-nohomeview-design.html</a></a><br>
                        </div>
                        <div> </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000">
                            <p> </p>
                            <p>7. Brief explanation.<br>
                                   Sugar provides a 'web services'
                              capability. However, these services are
                              only available to an XO which has
                              connection to the internet. This is not
                              useful to a large number of users who do
                              not have internet access. The school
                              server (e.g. XSCE) provides an alternative
                              to the internet for many deployments. This
                              task is to provide a capability on the
                              school server to support some or all of
                              the Sugar web services (e.g. by OwnCloud
                              or ELGG). <br>
                            </p>
                            <p>8. Brief explanation<br>
                                  There are a number of Sugar activities
                              which currently require access to the
                              internet (InfoSlicer, GetBooks). These
                              activities should have an option to
                              function with the school server. For
                              example, GetBooks could access books on
                              the school server and InfoSlicer could
                              create slices from Wikipedia on the school
                              server as Journal objects.<br>
                            </p>
                            <p>9. Brief explanation<br>
                                  Sugar users are often new to computers
                              and not familiar with other operating
                              systems. We need a mechanism to allow
                              users to more quickly develop skills in
                              using the capabilities of the XO
                              ('onboarding'). One proposal is to develop
                              scripts which lead the user through a
                              series of interactive steps illustrating
                              common usage of the XO with Sugar (<a
                                moz-do-not-send="true"
                                href="https://www.sam.today/blog/sugar-onboard-design.html"
                                target="_blank"><a class="moz-txt-link-freetext" href="https://www.sam.today/blog/sugar-onboard-design.html">https://www.sam.today/blog/sugar-onboard-design.html</a></a>).


                              This task is to implement an interpretive
                              system that allows <br>
                              deployments or experienced users to create
                              an 'onboard' script that guides the user
                              to carry out a task. The referenced
                              proposal suggests some user tasks where
                              this mechanism could be employed. Since
                              there is no finite list of these tasks, an
                              interpretive approach enables the scripts
                              to be created as necessary. <br>
                              For example, how does a user switch to the
                              Gnome desktop? A script could be created
                              guiding the user through the necessary
                              steps. How does the user make a screen
                              shot, use Gimp in the gnome desktop to
                              crop and resize, and then insert it as an
                              image in a Write document? How does the
                              user initiate or join a chat?<br>
                            </p>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I will actually be persuing that feature,
                          and the steps defined on that page as a
                          feature for 0.110.  Eventually it will have a
                          feature page, but it is the "onboard" branch
                          of <a moz-do-not-send="true"
href="https://github.com/samdroid-apps/%7Bsugar,sugar-artwork,sugar-toolkit-gtk3"
                            target="_blank">https://github.com/samdroid-apps/{sugar,sugar-artwork,sugar-toolkit-gtk3</a>}. 

                          I invite you to test the patches and provide
                          feedback.<br>
                        </div>
                        <div> </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000">
                            <p> </p>
                            <p>10. Brief explanation<br>
                                  Sugar is available on the XO and some
                              other platforms. In particular, Sugar is
                              available for 64-bit systems with Ubuntu
                              14.04 LTS installed (<a
                                moz-do-not-send="true"
                                href="http://wiki.sugarlabs.org/go/Ubuntu"
                                target="_blank"><a class="moz-txt-link-freetext" href="http://wiki.sugarlabs.org/go/Ubuntu">http://wiki.sugarlabs.org/go/Ubuntu</a></a>).



                              Unfortunately, this procedure does not
                              work with 32-bit systems. There exists an
                              opportunity to deploy Sugar <br>
                              with relatively inexpensive or refurbished
                              laptops which do not provide 64-bit
                              support. This task is to create a
                              comparable version of Sugar which can <br>
                              be installed on 32-bit systems as an
                              alternate Ubuntu desktop.<br>
                            </p>
                            <p>11. Brief explanation<br>
                                  Many deployments want to protect their
                              XOs against theft. OLPC provides an
                              'activation lease' mechanism in firmware
                              which makes it impossible to <br>
                              boot an XO once the activation lease has
                              expired, unless the XO has access to the
                              key via a removable device. This task is
                              to provide a similar mechanism which is
                              not dependent on OLPC. A USB key or
                              network device (school server) should have
                              an inventory of XOs identified by
                              serial_number (and, perhaps, uuid). if
                              this key is readable by the firmware, the
                              XO should boot. If the key is not readable
                              (e.g. reflash), then the XO should boot if
                              the key is readable on a removable device
                              or on the connected school server. [this
                              suggests the XO can connect to the
                              schoolserver by firmware alone - might be
                              difficult].  <br>
                                  Whenever an XO connects with the
                              network device, the network device should
                              confirm the activation lease and extend it
                              by a time specified by the deployment
                              (administrative owner of the network
                              device). A report should be available to
                              the deployment on the XO inventory and
                              when each was last connected to enable
                              detection of 'missing' XOs. Perhaps, the
                              mechanism should have a 'blacklist' of
                              serial_numbers of 'missing' laptops. If
                              such a laptop is connected, it could be
                              allowed to proceed with a warning to the
                              administrator that the 'missing' laptop is
                              in the house. This mechanism should be
                              available for optional implementation by a
                              deployment without reference to a central
                              organization such as OLPC.<br>
                            </p>
                            <p>12. Brief explanation<br>
                                  OLPC firmware in the XO-1 supported a
                              feature called 'nandblaster'. This
                              mechanism allowed a 'master' XO to
                              broadcast its image in a loop to the XO
                              Lan. Other XOs could then be flashed by
                              the firmware by making a copy of each
                              sector as it was broadcast to their local
                              store. Once a cycle in the loop was
                              finished, the XO could detach and was
                              ready for reboot with the newly installed
                              image. This task is to re-create this
                              capability where the 'master' XO image
                              could be on a network device such as a
                              school server or another XO. This
                              mechanism should store a new version of
                              firmware (as done currently) so that the
                              firmware upgrade can be automatically
                              installed on the next boot when connected
                              to an AC adapter. <br>
                            </p>
                            <p>13. Brief explanation<br>
                                  The OLPC model is that each user has
                              full possession and is the only user of an
                              XO laptop. Therefore, Sugar assumes a 1-1
                              correspondence between users and XO serial
                              numbers. However, Sugar is being used on
                              other platforms (e.g. SOAS), where there
                              is no obvious equivalent to a serial
                              number. SOAS and James Cameron have
                              created versions of Sugar which do not
                              assume the user is 'olpc', but implement a
                              standard username/password login system.
                              The users storage is allocated to his/her
                              home directory. <br>
                                  This task is to create a Sugar image
                              for the XO which allows for user's to
                              login by username and password. The basic
                              task is to move the Activities folder <br>
                              to a common space so that only one copy is
                              needed per system. This will support
                              deployments where one set of laptops are
                              shared across multiple classes (and users)
                              or where there one laptop is shared
                              between two students - one in a morning
                              shift and the other in an afternoon shift.
                              <br>
                            </p>
                            <p>14. Brief explanation<br>
                                  The TuxMath activity is popular with
                              deployments. However, the upstream version
                              appears to be abandoned. This task would
                              be to implement a sugar-web-activity math
                              game comparable to TuxMath.<br>
                                  <br>
                            </p>
                            <p>    <br>
                              I have some comments on the other tasks:<br>
                            </p>
                            <p>"The newer Sugar builds have performance
                              issues on <i>some old hardware</i> with
                              limited memory. This is keeping some Sugar
                              deployments from upgrading. This project
                              is to look into the performance issues and
                              tune Sugar for low-memory devices."<br>
                            </p>
                            <p>I think this task should be unambiguously
                              focused on the XO-1 (1GB store). The
                              majority of deployed XOs are XO-1s with a
                              1GB store. These deployments generally do
                              not have the funds to purchase and deploy
                              an SDHC card for these devices (ask Adam
                              about this possibility in Haiti, I was not
                              able to get a firm number from Rwanda but
                              I believe they may have deployed more than
                              several thousand XO-1s. The cost is not so
                              much the card itself, but the logistics
                              cost to prepare the cards with an XO-1
                              image and to deliver the cards to the
                              deployment locations). <br>
                            </p>
                            <p>The performance problem is not limited to
                              low-memory (250GB). It is also related to
                              no gpu, low persistent store, slower and
                              more limited processor and so on.). It is
                              also likely that their are specific
                              limitations on executing newer software
                              releases on this hardware. As a minimum,
                              someone who takes on this task needs an
                              XO-1 (and possibly access to an XO-1.5 for
                              performance comparisons - a task for the
                              mentor?).<br>
                            </p>
                            <p>One task could be to identify some
                              significant performance measures (a form
                              of benchmark which could be applied to all
                              models and releases to obtain <br>
                              relative performance measures). The task
                              also requires some analysis to determine
                              the bottlenecks limiting performance
                              (processor speed, graphics speed, memory
                              usage, storage access times, etc.). This,
                              in turn, requires defining important
                              workloads (boot, launch activity, switch
                              activities, shut down activity, shut down
                              system, connect to network, effective
                              network speed, and so on). I think the
                              community should be able to help with this
                              (what are the most significant tasks in
                              Haiti which have unacceptable response
                              times on the XO-1?). <br>
                            </p>
                            <p>It is likely that one result of this task
                              may be to limit the capabilities of Sugar
                              on the XO-1.<br>
                            </p>
                            <p>"Now that JavaScript has become a first
                              class citizen in the Sugar ecosystem, we
                              must re-design our collaboration model to
                              allow collaboration between web activities
                              regardless of the platform."</p>
                            <p>I am not sure what is meant here by
                              platform. Except for development
                              environments, I am only aware of
                              Sugarizer, SOAS, and Sugar on XO in the
                              wild (i.e in use by deployments without
                              any developers or computer professionals
                              on site). As I understood it, Sugar has
                              adopted the collab-wrapper model for Sugar
                              activities. Is this collab-wrapper usable
                              in a Javascript environment? Is is
                              possible for XO users to collaborate in
                              this model with users of SOAS or
                              Sugarizer?<br>
                            </p>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>Sugarizer has a different collab model
                          (some js thing) to the rest of Sugar. 
                          However, SoaS and XO are both running the same
                          Sugar, with the same collab model powered by
                          Telepathy.  I have use their collaboration
                          before.<br>
                        </div>
                        <div> </div>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor="#FFFFFF" text="#000000">
                            <p> </p>
                            <p>Nutritional Microworld<br>
                            </p>
                            <p>relevant tool—one that invites learners
                              to explore fundamental concepts of
                              nutrition that are both intrinsic to music
                              yet transcendent of a specific discipline.
                            </p>
                            I assume the reference to music is a typo. <br>
                            <br>
                            At Eurovision 2014, a speaker demonstrated
                            nsound - an alternative to csound. The claim
                            is a simpler and more understandable api.<br>
                            <br>
                            Turtle Confusion and Turtle Flags. <br>
                                These activities reproduce the Turtle
                            Blocks engine. I think a simpler solution is
                            to provide the confusion images and the flag
                            images via html and have the user create
                            them using the existing javascript Turtle
                            implementation. The user can easily switch
                            screens via alt-tab or the frame. For
                            example, the confusion challenges and the
                            flags could be presented by an .xol content.<br>
                            <p> </p>
                            <p>I'll try to send you some additional task
                              proposals as soon as I can.<br>
                            </p>
                          </div>
                          <div bgcolor="#FFFFFF" text="#000000">
                            <p>Tony<br>
                            </p>
                          </div>
                          <div bgcolor="#FFFFFF" text="#000000"> <br>
                            <br>
                            <div>On 02/19/2016 05:30 PM, Walter Bender
                              wrote:<br>
                            </div>
                            <blockquote type="cite">
                              <div dir="ltr">FYI, as per the discussion
                                at this month's SLOB meeting, I
                                submitted an application to Google
                                Summer of Code on behalf of Sugar Lbs.
                                Lionel has agreed to be the co-admin
                                this summer. We should hear by the end
                                of the month as to whether or not we are
                                accepted and how many slots we get. 
                                <div><br>
                                </div>
                                <div>It is important that we add some
                                  more potential projects to the list in
                                  the wiki over the next few days as a
                                  show of interest from the community.
                                  Please add your ideas to: </div>
                                <div><br>
                                </div>
                                <div><a moz-do-not-send="true"
                                    href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016"
                                    target="_blank">https://wiki.sugarlabs.org/go/Summer_of_Code/2016</a></div>
                                <div><br>
                                </div>
                                <div>Thanks.</div>
                                <div><br>
                                </div>
                                <div>-walter</div>
                                <div>
                                  <div><br>
                                  </div>
                                  -- <br>
                                  <div>
                                    <div dir="ltr">
                                      <div><font><font>Walter Bender</font></font><br>
                                        <font><font>Sugar Labs</font></font></div>
                                      <div><font><a
                                            moz-do-not-send="true"
                                            href="http://www.sugarlabs.org"
                                            target="_blank"><font><a class="moz-txt-link-freetext" href="http://www.sugarlabs.org">http://www.sugarlabs.org</a></font></a></font><br>
                                        <br>
                                      </div>
                                    </div>
                                  </div>
                                </div>
                              </div>
                              <br>
                              <fieldset></fieldset>
                              <br>
                              <pre>_______________________________________________
Sugar-devel mailing list
<a moz-do-not-send="true" href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
                            </blockquote>
                            <br>
                          </div>
_______________________________________________<br>
                          Sugar-devel mailing list<br>
                          <a moz-do-not-send="true"
                            href="mailto:Sugar-devel@lists.sugarlabs.org"
                            target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
                          <a moz-do-not-send="true"
                            href="http://lists.sugarlabs.org/listinfo/sugar-devel"
                            rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
                        </blockquote>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            Sugar-devel mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.sugarlabs.org/listinfo/sugar-devel"
              rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>