<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 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 href="https://www.sam.today/blog/sugar-nohomeview-design.html" target="_blank"></a><a 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 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 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 href="https://www.sam.today/blog/sugar-nohomeview-design.html" target="_blank">https://www.sam.today/blog/sugar-nohomeview-design.html</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 href="https://www.sam.today/blog/sugar-onboard-design.html" target="_blank"></a><a href="https://www.sam.today/blog/sugar-onboard-design.html" target="_blank">https://www.sam.today/blog/sugar-onboard-design.html</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 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 href="http://wiki.sugarlabs.org/go/Ubuntu" target="_blank"></a><a href="http://wiki.sugarlabs.org/go/Ubuntu" target="_blank">http://wiki.sugarlabs.org/go/Ubuntu</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 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 href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br>
                          <br>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
                <br>
                <fieldset></fieldset>
                <br>
                <pre>_______________________________________________
Sugar-devel mailing list
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a 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 href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
            <a 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 href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a 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>