<div dir="ltr">Aside to Tony's remarks below: JerryV & TimM have many details on the likely/imminent upgrade to ownCloud 8 as a part of XSCE 6.1, for those who missed Thursday's meeting (<a href="http://tinyurl.com/xsceminutes">http://tinyurl.com/xsceminutes</a>).<br><br><div><br>From: <b class="gmail_sendername">Tony Anderson</b> <span dir="ltr"><<a href="mailto:tony_anderson@usa.net">tony_anderson@usa.net</a>></span><br><div class="gmail_quote">Date: Fri, Apr 15, 2016 at 8:43 PM<br>Subject: Re: [Sugar-devel] Sugar-Server enhancement<br>To: <a href="mailto:sugar-devel@lists.sugarlabs.org">sugar-devel@lists.sugarlabs.org</a><br><br>
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Re OwnCloud<br>
    <br>
    The software is included in xsce; however, the last time I tried it
    was not configured. The key in OwnCloud is configuration (db, etc.).
    <br>
    <br>
    One concern I have is that we have a way to authenticate users. We
    are growing the number of server 'services' which require a username
    and password. <br>
    I think we should look into enabling LDAP to provide a common
    authentication across the school server. This, of course, gets into
    the issue of whether we are authenticating users or device
    serial-numbers. My recommendation is small steps - moving the backup
    from /library/user/ is not a small step.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Tony</font></span><div><div class="h5"><br>
    <br>
    <div>On 04/16/2016 07:56 AM, Manash Raja
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">@James,<br>
        <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">1. 
          you're changing "Register" and "Register again" to "Connect to<br>
          server", but it isn't clear in the commit message why it is
          necessary;</blockquote>
        <div>I felt as "Register" refers to an action done for first
          time (Add new laptop entry in the server), while "Register
          again" means to redo the same thing (Add another entry of the
          same laptop in the server). But now as registration is done
          only once, while at other times, Sugar only changes a few
          setting to adapt. Hence I felt to keep a constant name
          "Connect to server" as it does not bother the user if he/she
          if connecting to the server for the first time or otherwise,
          as things are taken care of in the background. Just gave a
          thought. Nevertheless, it also just say "Register" always.<br>
          <br>
          <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">please
            avoid `ssh-keygen -R` if server is unchanged, because<br>
            otherwise a rogue server can be introduced after
            registration,<br>
            <br>
            (Would it be possible to change .ssh/config to add an entry
            for each<br>
            server?  If so, the known_hosts file might not need changing
            at all).</blockquote>
          <div>I don't know much about the ssh host verification though,
            but I am learning it and will come up with something better.
            We can edit the .ssh/config file as it doesn't require root
            permission. Can you tell me what entry would be there for
            each server and do we just have to keep adding or we will
            have to manage it also?<br>
            <br>
            <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">please check for `os.command()`
              failure, which could happen if the<br>
              disk is full, </blockquote>
            <div>Do you mean '<span>os.system(command)'? <br>
                <br>
              </span><span></span>
              <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">please
                add commit message references to the server-side changes<br>
                and invite <a href="mailto:server-devel@lists.laptop.org" target="_blank">server-devel@lists.laptop.org</a>
                people with your feature page<br>
                and patch.</blockquote>
              <div>I didn't do any modification to the server side for
                this. Just setup the server with "Services for XO
                laptops ...." enabled in the schoolserver admin page.
                Though I have added this to my commit message. Updated
                commit message: <a href="https://github.com/ManashRaja/sugar/commit/3ad4d847d0f2373d5bfe9f6c8e201b358f3f68e0" target="_blank">https://github.com/ManashRaja/sugar/commit/3ad4d847d0f2373d5bfe9f6c8e201b358f3f68e0</a><br>
                <br>
              </div>
              @Jerry,<br>
            </div>
            <div>I haven't modified anything for this feature on the
              server side. I found that it uses both idmgr and
              xs-authserver. But the 5000 port is used by xs-authserver
              to display a list of registered laptops. I didn't enable
              it myself, it was there. All I did was to setup my server
              according to the instructions and enabled the "XO
              register" feature from the admin page.<br>
              <br>
            </div>
            <div>@Tony,<br>
            </div>
            <div>Can you tell me how ownCloud is supported by XSCE? I
              saw it in the services ready to be enabled. So can we not
              move the storage location of /library/user/<some_id>
              inside or account based user directories to the cloud
              storage locations.<br>
              <br>
            </div>
            <div>Thanks<br>
            </div>
          </div>
          <br>
           <br>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Sat, Apr 16, 2016 at 3:23 AM,
            Jerry Vonau <span dir="ltr"><<a href="mailto:me@jvonau.ca" target="_blank">me@jvonau.ca</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
                > On April 15, 2016 at 4:18 PM Manash Raja <<a href="mailto:mpdmanash@gmail.com" target="_blank"></a><a href="mailto:mpdmanash@gmail.com" target="_blank">mpdmanash@gmail.com</a>>
                wrote:<br>
                ><br>
                ><br>
                > Hi all,<br>
                ><br>
                > I fixed the bug. I haven't created a PR just yet.<br>
                > <a href="https://github.com/ManashRaja/sugar/commit/660985d2183416cd3ed758095e92adf82f87a10c" rel="noreferrer" target="_blank">https://github.com/ManashRaja/sugar/commit/660985d2183416cd3ed758095e92adf82f87a10c</a><br>
                > As of now I am parsing HTML data for json data to
                look for registered<br>
                > laptops at an XS from the webaddress <a href="http://schoolserver:5000" rel="noreferrer" target="_blank"></a><a href="http://schoolserver:5000" target="_blank">http://schoolserver:5000</a>
                that serves<br>
                > a<br>
                > liist of registered laptops.<br>
                <br>
              </span>Interesting, 'idmgr' doesn't use port 5000, are you
              using 'authserver' on<br>
              the XSCE? Little background, idmgr was released by OLPC
              while authserver<br>
              originates from ActivityCentral's dextrose work. I have no
              knowledge of<br>
              which method was deployed by what deployment the XSCE
              project tries to<br>
              cover all deployments' needs, that is why both are
              present. Better check<br>
              with Walter about using dextrose code, that might be
              frowned upon.<br>
              <span><br>
                > I will modify it if there is another better method
                that can be<br>
                > implemented<br>
                > from the Sugar side (we don't intend to modify the
                server side I guess).<br>
                ><br>
                <br>
              </span>Think you better plan to work on the server side
              also, you'll have a clean<br>
              slate to work with.<br>
              <span><br>
                > And here is the feature page as suggested by James.<br>
                > <a href="https://wiki.sugarlabs.org/go/Features/Multi_XS-server_registration" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Features/Multi_XS-server_registration</a><br>
                ><br>
                > Please have a look.<br>
                ><br>
                > I am very excited to be a part of the discussions
                that go into the making<br>
                > of great features that can affect people down there
                in deployment. :)<br>
                > There<br>
                > is a scope to do so much.<br>
                ><br>
                > Thanks<br>
                ><br>
                <br>
              </span><span><font color="#888888">Jerry<br>
                </font></span>
              <div>
                <div><br>
                  > On Sat, Apr 16, 2016 at 2:32 AM, James Cameron
                  <<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>>
                  wrote:<br>
                  ><br>
                  > > On Fri, Apr 15, 2016 at 04:02:39PM +0800,
                  Tony Anderson wrote:<br>
                  > > > Hi, James<br>
                  > > ><br>
                  > > > This thread was getting long so I
                  replied only to the most recent<br>
                  > > > communication. I am sure you have the
                  full thread which shows the<br>
                  > > > scope of the discussion.<br>
                  > ><br>
                  > > You're making it longer, yes, by hijacking
                  it.  You can find the full<br>
                  > > thread here:<br>
                  > ><br>
                  > > <a href="http://lists.sugarlabs.org/archive/sugar-devel/2016-April/thread.html" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/archive/sugar-devel/2016-April/thread.html</a><br>
                  > ><br>
                  > > > According to trac bug #362 was opened
                  seven years ago against 0.82<br>
                  > > > and last looked at three years ago.
                  Several competent people looked<br>
                  > > > at it and left comments. I see none
                  that signify consensus.<br>
                  > ><br>
                  > > I take it that you don't want Manash to fix
                  this bug, thanks.<br>
                  > ><br>
                  > > I'd like it fixed.  I think there are others
                  who want it fixed.  It<br>
                  > > would probably help with XS testing as well.<br>
                  > ><br>
                  > > > To have a design discussion, it is
                  valuable to have a proposed<br>
                  > > > design.<br>
                  > > ><br>
                  > > > I have tried to explain my proposal in
                  detail. If there are<br>
                  > > > questions, I would be happy to try to
                  respond. Fixing the 'Journal<br>
                  > > > is Full' dialog is a major help.
                  However, what do you recommend to<br>
                  > > > deployments when this happens?<br>
                  > ><br>
                  > > 1.  upgrade to Sugar 0.108 (by RPM or
                  images), or backport the patch<br>
                  > > [#9623, #1720] into your custom builds,<br>
                  > ><br>
                  > > 2.  transcode content to play in browser not
                  Journal,<br>
                  > ><br>
                  > > 3.  delete any activities that are not
                  needed,<br>
                  > ><br>
                  > > 4.  deploy Sugar Network to use the network
                  activity cache,<br>
                  > ><br>
                  > > Also delete the Browse temporary
                  directories, you reported this on<br>
                  > > 19th January, it remains a problem, and you
                  refused to test my fix, so<br>
                  > > I lost interest very rapidly.  [#4931]<br>
                  > ><br>
                  > > > The bottom line is that a reasonably
                  active user is likely to need<br>
                  > > > more room to store her Journal than is
                  available on the XO.<br>
                  > ><br>
                  > > No, because it's no longer a significant
                  problem.  XO-1 are in the<br>
                  > > minority and getting rarer as they die. 
                  Those that haven't died have<br>
                  > > SD cards.<br>
                  > ><br>
                  > > > In the Journal code a filled star sets
                  the 'keep' flag in the<br>
                  > > > metadata. The cleared star clears the
                  'keep' flag in the metadata.<br>
                  > > > Using this feature greatly simplifies
                  the coding and the Journal<br>
                  > > > view. As far as I know, the only use of
                  this at the moment is to<br>
                  > > > support the Portfolio activity.<br>
                  > ><br>
                  > > You are using an implementation detail in
                  describing the flag.  The<br>
                  > > name given to the flag in documentation and
                  user interface is<br>
                  > > "favorite" (sic).<br>
                  > ><br>
                  > > > I think the detail view is
                  inappropriate exactly as it would be to<br>
                  > > > move the multiple selection checkbox
                  there. These controls need to<br>
                  > > > be immediately available.<br>
                  > ><br>
                  > > I disagree; they won't get used, and so it
                  would be a waste of<br>
                  > > valuable vertical space.  The reason the
                  checkbox won't get used is;<br>
                  > ><br>
                  > > - most laptops don't have a server,<br>
                  > ><br>
                  > > - an LRU algorithm can maintain the cache
                  effectively.<br>
                  > ><br>
                  > > > The 'backup/sync' script is a good
                  place to do check storage quotas<br>
                  > > > because the script needs to touch the
                  datastore on a regular basis.<br>
                  > > > It has access to the amount of store in
                  use and the LRU information.<br>
                  > > > For example, if the user wants a
                  document downloaded, the script<br>
                  > > > knows its size and whether some other
                  local copies need to be<br>
                  > > > deleted to make room.<br>
                  > ><br>
                  > > I disagree.  This script runs infrequently. 
                  The LRU must be<br>
                  > > implemented inside the datastore for it to
                  function properly.<br>
                  > > Otherwise the lag between user action and
                  response by the script would<br>
                  > > be too long.<br>
                  > ><br>
                  > > > While an implementation detail, so far
                  no change has been necessary<br>
                  > > > to the datastore class.<br>
                  > ><br>
                  > > That's no reason not to change it.<br>
                  > ><br>
                  > > > Actually, since the 'keep' or favorite
                  star sets the metadata,<br>
                  > > > so far there has been no need to change
                  the Journal.<br>
                  > ><br>
                  > > That's no reason not to change it.<br>
                  > ><br>
                  > > > "The multiple user feature is supported
                  by Fedora and Sugar, but we<br>
                  > > > removed it for OLPC OS."<br>
                  > > ><br>
                  > > > I think I am beginning to understand.
                  OLPC OS is your generic name<br>
                  > > > for the images to be installed on each
                  model of the XO.<br>
                  > ><br>
                  > > Really, you are out of touch!  OLPC OS is
                  our name for the operating<br>
                  > > system releases on the XO laptop.  We've
                  been using the term at OLPC<br>
                  > > for a very long time, and use it in each
                  release announcement.<br>
                  > ><br>
                  > > > I am deploying build 13.2.5 with Sugar
                  0.106 on all models.<br>
                  > ><br>
                  > > That's so sad.  It was released in July
                  2015.  It has the journal full<br>
                  > > bug you mentioned.  I'm not interested in
                  supporting that release,<br>
                  > > because I've already released two others. 
                  Upgrade.<br>
                  > ><br>
                  > > > So you are saying that we, users of
                  Sugar or ' OLPC OS' could have a<br>
                  > > > multiple user version of Sugar if
                  'you', as developers, didn't<br>
                  > > > remove it.<br>
                  > ><br>
                  > > Well done.<br>
                  > ><br>
                  > > > As I understand it, you propose to
                  generate unique serial-numbers<br>
                  > > > per user.<br>
                  > ><br>
                  > > No.  I was describing what happens _now_
                  during registration, by<br>
                  > > reference to the code:<br>
                  > ><br>
                  > > 1.  for XO laptops the serial number of the
                  laptop is used,<br>
                  > ><br>
                  > > 2.  for non-XO laptops a serial number is
                  generated randomly,<br>
                  > ><br>
                  > > 3.  there is no attempt to ensure the random
                  serial number is<br>
                  > > unique, but the width of the random string
                  is sufficient to make it<br>
                  > > unlikely,<br>
                  > ><br>
                  > > > So SSO would be guaranteed since no two
                  users could have<br>
                  > > > the same serial-number. This would
                  certainly work and probably<br>
                  > > > involve very little change to the
                  existing code. What will be needed<br>
                  > > > is a 'dns' to map serial-numbers to
                  usernames.<br>
                  > ><br>
                  > > No, I wasn't proposing that.  It's your
                  idea.  I don't think it's<br>
                  > > guaranteed to be unique though.<br>
                  > ><br>
                  > > > Every school I have worked with keeps a
                  careful record of students<br>
                  > > > (often in paper ledgers). Currently I
                  provide a name record in a<br>
                  > > > Django database on the server (along
                  with an XO inventory by serial<br>
                  > > > number).<br>
                  > ><br>
                  > > Fail to see relevance.  Not all schools will
                  or can do this.<br>
                  > ><br>
                  > > > Agreed that determining which Journal
                  objects need to be saved to<br>
                  > > > the school server is not a difficult
                  problem. However, datastore is<br>
                  > > > a class so each user's datastore and
                  the common datastore would be<br>
                  > > > instances. So this seemed like a simple
                  thing to implement.<br>
                  > > ><br>
                  > > > Actually, The deletion of Journal
                  objects without an associated<br>
                  > > > document works amazingly well. The
                  number of objects in the Journal<br>
                  > > > view goes from hundreds to only a few
                  (often less than 20).<br>
                  > > > Moreover, these 20 are the obviously
                  interesting ones. Nothing is<br>
                  > > > lost as the metadata is saved to the
                  school server. It becomes much<br>
                  > > > easier to 'reflect' when you are only
                  looking at the documents you<br>
                  > > > created. Meanwhile the myriad of
                  objects can be subject to<br>
                  > > > statistical analysis.<br>
                  > > ><br>
                  > > > For many activities, such as the
                  Terminal, the document saved is<br>
                  > > > actually 'state' information. This
                  allows the Terminal activity to<br>
                  > > > be restored with tabs and pwd. There
                  are many game activities such<br>
                  > > > as Memorize that also store state. It
                  would seem more appropriate to<br>
                  > > > save this state information in the
                  metadata. For example, a json<br>
                  > > > could be created in the metadata to
                  hold state information. The<br>
                  > > > script could keep these objects to
                  enable the user to resume.<br>
                  > ><br>
                  > > Your concept of metadata is not of interest
                  to me; journal objects<br>
                  > > must continue reflect the learner's use of
                  the laptop if the journal<br>
                  > > is to meet the designed style of reflection.<br>
                  > ><br>
                  > > Unreflecting adults are not the target user.<br>
                  > ><br>
                  > > ><br>
                  > > > Tony<br>
                  > > ><br>
                  > > > On 04/15/2016 01:36 PM, James Cameron
                  wrote:<br>
                  > > > >On Fri, Apr 15, 2016 at 10:25:59AM
                  +0800, Tony Anderson wrote:<br>
                  > > > >>Hi Manash<br>
                  > > > >><br>
                  > > > >>The registration process is
                  awkward but not the problem.<br>
                  > > > >This is unfair scope creep.  Manash
                  began by asking about bug #362<br>
                  > > > >and<br>
                  > > > >has been working to fix that.  Now
                  you're asking him to consider a<br>
                  > > > >much larger task; not a coding
                  task, but a redesign of Sugar Journal<br>
                  > > > >and Backup interaction.  This is
                  huge.<br>
                  > > > ><br>
                  > > > >And as far as I can tell, students
                  aren't even accepted yet [1].<br>
                  > > > ><br>
                  > > > >1.  <a href="https://en.wikipedia.org/wiki/Google_Summer_of_Code#2016" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Google_Summer_of_Code#2016</a><br>
                  > > > ><br>
                  > > > >What you propose is from a set of
                  tasks [2] you added to the Wiki,<br>
                  > > > >which have not undergone any design
                  review according to Sugar Labs<br>
                  > > > >design practice and feature
                  policy.  I do not see any consensus on<br>
                  > > > >these; we're yet to build a
                  consensus.<br>
                  > > > ><br>
                  > > > >2.<br>
                  > > <a href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_on_the_Ground" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_on_the_Ground</a><br>
                  > > > ><br>
                  > > > >Or, it looks like you're trying to
                  make your own fork of Sugar,<br>
                  > > > >which<br>
                  > > > >I'm fine with, it's open source
                  after all, but to push that on<br>
                  > > > >others<br>
                  > > > >without their input is wrong.<br>
                  > > > ><br>
                  > > > >If you proceed without consensus as
                  a sole designer, then OLPC will<br>
                  > > > >fork Sugar (as we already have so
                  that XO-1s will go faster), and<br>
                  > > > >you'll be making your own builds.<br>
                  > > > ><br>
                  > > > >>The problem is that rsync is
                  used to create backups of the Journal<br>
                  > > > >>and no effective means is
                  offered to restore.<br>
                  > > > >Agreed.  We have no restore from
                  server feature in Sugar 0.108,<br>
                  > > > >along<br>
                  > > > >with no way to start a backup to
                  server, and no selective restore.<br>
                  > > > ><br>
                  > > > >(We have backup to media, restore
                  from media, but no selective<br>
                  > > > >restore from media.  Also, restore
                  from media replaces Journal!)<br>
                  > > > ><br>
                  > > > >>However, the ultimate problem
                  is thinking of the problem as one of<br>
                  > > > >>backup. If you try to solve the
                  wrong problem, often the result is<br>
                  > > > >>a<br>
                  > > > >>wasted effort.<br>
                  > > > >><br>
                  > > > >>The Journal is single place
                  where Sugar users save their documents.<br>
                  > > > >>This is done by the Sugar
                  activities when they close. The majority<br>
                  > > > >>of XOs are still XO-1s with a
                  1GB store.<br>
                  > > > >This point in your argument is
                  void, because XO-1 are 45% of the XO<br>
                  > > > >laptops manufactured so far.  I
                  have the numbers.<br>
                  > > > ><br>
                  > > > >Also, many XO-1 have been upgraded
                  with an SD card.<br>
                  > > > ><br>
                  > > > >>If the available store is less
                  than 50GB,<br>
                  > > > >No, that's 50 MB, not 50 GB.  See
                  _SPACE_TRESHOLD (sic) in<br>
                  > > >
                  >sugar:src/jarabe/journal/journalactivity.py [3].<br>
                  > > > ><br>
                  > > > >3.<br>
                  > > <a href="https://github.com/sugarlabs/sugar/blob/master/src/jarabe/journal/journalactivity.py#L56" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar/blob/master/src/jarabe/journal/journalactivity.py#L56</a><br>
                  > > > ><br>
                  > > > >>Sugar effectively shuts down.<br>
                  > > > >This point in your argument is
                  void, because this has been fixed [4,<br>
                  > > > >5, 6], please upgrade to Sugar
                  0.108 which is in OLPC OS 13.2.7 [6].<br>
                  > > > ><br>
                  > > > >4.  <a href="http://dev.laptop.org/ticket/9623" rel="noreferrer" target="_blank">http://dev.laptop.org/ticket/9623</a><br>
                  > > > >5.  <a href="https://bugs.sugarlabs.org/ticket/1720" rel="noreferrer" target="_blank">https://bugs.sugarlabs.org/ticket/1720</a><br>
                  > > > >6.  <a href="http://wiki.laptop.org/go/Release_notes/13.2.7#Fixes" rel="noreferrer" target="_blank">http://wiki.laptop.org/go/Release_notes/13.2.7#Fixes</a><br>
                  > > > ><br>
                  > > > >>This typically results in the
                  deployment reflashing the XO erasing<br>
                  > > > >>all of the documents created by
                  that user - a tragedy.<br>
                  > > > >It was a known bug, so that's a
                  training issue.  You previously<br>
                  > > > >proposed to train a teacher to use
                  "rm -rf" to delete a known_hosts<br>
                  > > > >file instead of Manash coding up an
                  "ssh-keygen -R" command.  It is<br>
                  > > > >inconsistent to be able to do one
                  and not the other.<br>
                  > > > ><br>
                  > > > >>What I am proposing is to use
                  the school server as the primary<br>
                  > > > >>store<br>
                  > > > >>for the Journal with its
                  effectively unlimited storage capacity.<br>
                  > > > >>The<br>
                  > > > >>ds_backup script needs to read
                  the datastore uploading any new or<br>
                  > > > >>modified documents. The local
                  datastore can then be viewed as a<br>
                  > > > >>cache for current working
                  documents.<br>
                  > > > >I'm favour of this ideal in
                  principle, but it remains a huge design<br>
                  > > > >and consensus challenge, not a
                  coding challenge.<br>
                  > > > ><br>
                  > > > >However, with the XO-1, XO-1.5 and
                  XO-1.75 using IEEE 802.11g the<br>
                  > > > >local wireless network will
                  collapse sooner due to this new load.<br>
                  > > > ><br>
                  > > > >>On the XO, the datastore is
                  shown in the Journal. The 'keep' star<br>
                  > > > >There's no such thing.  There's a
                  favorite star [7].  It has a<br>
                  > > > >defined<br>
                  > > > >purpose.  Are you proposing to
                  destroy that purpose, or add another<br>
                  > > > >column to the journal?  There's
                  even less room now that the multiple<br>
                  > > > >selection checkbox was added.<br>
                  > > > ><br>
                  > > > >7.  <a href="https://help.sugarlabs.org/en/journal.html#journal-features" rel="noreferrer" target="_blank">https://help.sugarlabs.org/en/journal.html#journal-features</a><br>
                  > > > ><br>
                  > > > >>could be used to show whether
                  there is a local copy of that<br>
                  > > > >>document<br>
                  > > > >>or not. If the document is not
                  needed locally, the user can clear<br>
                  > > > >>the star. In this case, the
                  backup script could delete the local<br>
                  > > > >>copy. If there is no local copy
                  of the document, then the user<br>
                  > > > >>could<br>
                  > > > >>set the star. In this case the
                  backup script could download the<br>
                  > > > >>document.<br>
                  > > > >My preference would be for the flag
                  to be in the Journal detail<br>
                  > > > >view [8], where there is available
                  display space.<br>
                  > > > ><br>
                  > > > >8.  <a href="https://help.sugarlabs.org/en/journal.html#journal-detail-view" rel="noreferrer" target="_blank">https://help.sugarlabs.org/en/journal.html#journal-detail-view</a><br>
                  > > > ><br>
                  > > > >>This capability could be used
                  to set a quota on the amount of space<br>
                  > > > >>used by the Journal. If the
                  space is exceeded, the 'backup' script<br>
                  > > > >>could delete local copies of
                  document by LRU until the quota is<br>
                  > > > >>met.<br>
                  > > > >>Similarly, there should be a
                  quota on Sugar activities which could<br>
                  > > > >>also automatically be pruned
                  back LRU. Managing the store<br>
                  > > > >>automatically is consistent
                  with keeping the Sugar UI as simple as<br>
                  > > > >>possible.<br>
                  > > > >This should be built into Sugar
                  rather than in the non-Sugar backup<br>
                  > > > >script.  They should be maintained
                  together.<br>
                  > > > ><br>
                  > > > >This would be a code change to git
                  repository sugar-datastore and<br>
                  > > > >the<br>
                  > > > >Journal activity in repository
                  sugar.<br>
                  > > > ><br>
                  > > > >>As always, there are
                  complications. The original OLPC concept was<br>
                  > > > >>that there would be one XO per
                  user. As a result the software was<br>
                  > > > >>designed for a single user
                  identified by the XO serial number.<br>
                  > > > >The multiple user feature is
                  supported by Fedora and Sugar, but we<br>
                  > > > >removed it for OLPC OS.<br>
                  > > > ><br>
                  > > > >>Today, many XO deployments
                  provide enough XOs for a classroom.<br>
                  > > > >>During the day, different
                  students use the XO as their class goes<br>
                  > > > >>to<br>
                  > > > >>the computer lab or as the
                  computers are distributed from classroom<br>
                  > > > >>to classroom. However, all of
                  the documents created are in a single<br>
                  > > > >>Journal with only the user's
                  memory to indicate which document goes<br>
                  > > > >>with which user.<br>
                  > > > >OLPC did not design OLPC OS to be
                  used in this scenario, so no<br>
                  > > > >surprise you've hit that.  But it's
                  not a Sugar problem.  Don't<br>
                  > > > >conflate Sugar with OLPC OS.<br>
                  > > > ><br>
                  > > > >>The OLPC Ubuntu Sugar 14.04
                  Trusty LTS (to use its official name)<br>
                  > > > >>solves this problem at the
                  laptop side by using standard gnu/linux<br>
                  > > > >>logins.<br>
                  > > > >The multiple user feature is
                  supported by Ubuntu and Sugar, and I<br>
                  > > > >haven't removed it yet.  I know how
                  to; small configuration change<br>
                  > > > >to<br>
                  > > > >lightdm package.<br>
                  > > > ><br>
                  > > > >Don't forget SoaS.  The Fedora 23
                  SoaS is easily installed to disk<br>
                  > > > >and<br>
                  > > > >has multiple user capability.  The
                  Fedora 24 SoaS is shaping up to<br>
                  > > > >be<br>
                  > > > >just as good or better, since it is
                  based on Sugar 0.108.<br>
                  > > > ><br>
                  > > > >>Each user has her own username
                  and password. The Sugar activities<br>
                  > > > >>have been moved to common space
                  in the file system so only one copy<br>
                  > > > >>is needed to support multiple
                  users. Users are not 'olpc' but<br>
                  > > > >>identified by their username. 
                  However, the datastore is part of<br>
                  > > > >>the<br>
                  > > > >>user space (one datastore per
                  user).<br>
                  > > > >Yes.  ODPU.<br>
                  > > > ><br>
                  > > > >>This is problematic since the
                  backup script uploads to<br>
                  > > > >>/library/user/serial-number on
                  the school server.<br>
                  > > > >No, you're wrong.  In the Ubuntu
                  scenario, the register_laptop<br>
                  > > > >function will invent a serial
                  number because it won't find Open<br>
                  > > > >Firmware [1].  So it wouldn't be a
                  problem.  It doesn't sound like<br>
                  > > > >you've tested this.<br>
                  > > > ><br>
                  > > > >1.<br>
                  > > <a href="https://github.com/sugarlabs/sugar/blob/master/src/jarabe/desktop/schoolserver.py#L110" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar/blob/master/src/jarabe/desktop/schoolserver.py#L110</a><br>
                  > > > ><br>
                  > > > >>So, one strategy would be to
                  upload to /library/user/username. This<br>
                  > > > >>requires that usernames be
                  unique across all laptops using a given<br>
                  > > > >>schoolserver. This could be
                  enforced at registration on the school<br>
                  > > > >>server.<br>
                  > > > >Starting to sound very
                  complicated.  Single-sign-on (SSO) across a<br>
                  > > > >school.  These are truly amazing
                  teachers with lots of free<br>
                  > > > >administration time.<br>
                  > > > ><br>
                  > > > >(There are deployments using Sugar
                  with SSO already, but as it's<br>
                  > > > >outside the scope of Sugar we don't
                  hear about them at Sugar Labs,<br>
                  > > > >and<br>
                  > > > >we don't provide the facility in
                  OLPC OS, but that doesn't stop<br>
                  > > > >them.)<br>
                  > > > ><br>
                  > > > >>However, the Sugar releases for
                  the XO<br>
                  > > > >We call that OLPC OS, which
                  includes Sugar and Gnome desktops.<br>
                  > > > ><br>
                  > > > >>still maintains Sugar
                  activities in /home/olpc/Activities. So, one<br>
                  > > > >>requirement is to restructure
                  Sugar as was done for OLPC Ubuntu<br>
                  > > > >>Sugar 14.04 Trusty LTS.<br>
                  > > > >That would not block implementing a
                  server datastore, since the<br>
                  > > > >implementation would not care what
                  $HOME is set to.<br>
                  > > > ><br>
                  > > > >(And besides, it's already done for
                  SoaS, so the Fedora activity<br>
                  > > > >packages can be used immediately.)<br>
                  > > > ><br>
                  > > > >>Another approach might be to
                  create directories for each user of a<br>
                  > > > >>single XO (e.g. 
                  /library/user/serial-number/user1).<br>
                  > > > >That would require authentication
                  service by the server datastore.<br>
                  > > > ><br>
                  > > > >>Another complication is that
                  the Browse activity downloads files<br>
                  > > > >>from the school server to the
                  Journal (e.g. pdfs, mp3). These<br>
                  > > > >>documents do not need to be
                  saved to the users Journal backup on<br>
                  > > > >>the<br>
                  > > > >>school server since they can be
                  restored from the school server<br>
                  > > > >>'library'. Also, such documents
                  when downloaded should be stored in<br>
                  > > > >>a common space available to all
                  users of that laptop. Fortunately,<br>
                  > > > >>the source of a document is
                  provided in the metadata.<br>
                  > > > >What you describe here can also be
                  solved by deduplication.<br>
                  > > > ><br>
                  > > > >The Journal Git backend proposed by
                  Martin and Walter could help<br>
                  > > > >with<br>
                  > > > >deduplication of journal objects
                  across multiple journals.<br>
                  > > > ><br>
                  > > > ><a href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_Core" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_Core</a><br>
                  > > > ><br>
                  > > > >>One approach would be to divide
                  the datastore into two directories<br>
                  > > > >>on the laptop, one in common
                  space and the other local to the user.<br>
                  > > > >>The Journal could show both
                  sets of objects.<br>
                  > > > >Or the server datastore would
                  recognise content hashes of server<br>
                  > > > >artefacts and know it need not send
                  the content from the client to<br>
                  > > > >the<br>
                  > > > >server before LRU local deletion. 
                  It could hard link it.<br>
                  > > > ><br>
                  > > > >>Finally, each Journal object
                  consists of a metadata file and an<br>
                  > > > >>optional document. The metadata
                  files tend to clutter the Journal<br>
                  > > > >>display (mine has hundreds of
                  Terminal activity and Log activity<br>
                  > > > >>entries). I would propose that
                  the Journal show only objects which<br>
                  > > > >>have a document with a
                  user-supplied name (a metadata flag). The<br>
                  > > > >>script should backup the
                  metadata files for those objects without a<br>
                  > > > >>document to a 'log' on the
                  school server for statistical analysis<br>
                  > > > >>but delete them from the local
                  datastore. Journal objects saved<br>
                  > > > >>without a user-supplied name
                  (but something like Write.activity)<br>
                  > > > >>should have their document
                  deleted. As part of GSOC there is an<br>
                  > > > >>initiative to require users to
                  supply a name for documents they<br>
                  > > > >>wish<br>
                  > > > >>to save - so this problem may
                  not be part of the 'backup' scheme.<br>
                  > > > >>Whether a document is saved or
                  deleted, the metadata can be saved<br>
                  > > > >>to<br>
                  > > > >>the log and displayed by the
                  existing statistical tools.<br>
                  > > > >I'm against any classification of
                  journal objects in this way.  We<br>
                  > > > >cannot know how useful a Terminal
                  and Log activity object is to the<br>
                  > > > >learner.<br>
                  > > > ><br>
                  > > > >However, I would like a way for
                  expert users to terminate an<br>
                  > > > >activity<br>
                  > > > >without saving a journal object.<br>
                  > > > ><br>
                  > > > >>As an old crumudgeon, I still
                  believe design precedes coding.<br>
                  > > > >><br>
                  > > > >>Reading the existing code is
                  always a good idea:<br>
                  > > > >><br>
                  > > > >>Sugar<br>
                  > > > >><br>
                  > > > >>     *<br>
                  > > >
                  >>/usr/lib/python2.7/site-packages/jarabe/desktop/schoolserver.py<br>
                  > > > >>#registers server - notice
                  transition from gconf to gsettings<br>
                  > > > >>     * /usr/bin/ds_backup.sh   
                  #primarily decides if backup can be<br>
                  > > > >> run<br>
                  > > > >>                               
                                #backup logic is<br>
                  > > > >> needed<br>
                  > > > >>because an rsync can use a lot
                  of bandwidth in a local network<br>
                  > > > >>     * /usr/bin/ds_backup.py   
                  #actually does the backup using<br>
                  > > > >> rsync<br>
                  > > > >>(note: -d option AFAIK deletes
                  an object from the backup if it is<br>
                  > > > >>deleted in the source,<br>
                  > > > >>                               
                                #this has the effect<br>
                  > > > >> of<br>
                  > > > >>limiting the size of the
                  datastore to the available space on the XO<br>
                  > > > >>not on the school server).<br>
                  > > > >><br>
                  > > > >>Server (xsce6)<br>
                  > > > >><br>
                  > > > >>     * /usr/libexec/idmgr     
                     #contains a number of utilities<br>
                  > > > >>used in registration<br>
                  > > > >>     * /library/users         
                         #contains a directory per<br>
                  > > > >>serial-number of registered
                  user<br>
                  > > > >>                               
                               #use ls -a to see<br>
                  > > > >> files<br>
                  > > > >>created. The idmgr creates a
                  public/private key pair which is used<br>
                  > > > >>by sftp to authenticate -
                  avoiding password<br>
                  > > > >><br>
                  > > > >>Note: if you look at the server
                  code, you can see why registering<br>
                  > > > >>the laptop on each connection
                  works (and can avoid any need for a<br>
                  > > > >>registration menu item).<br>
                  > > > >><br>
                  > > > >>When you get to know your way
                  around the existing process, I'll<br>
                  > > > >>send<br>
                  > > > >>you a copy of the ds_backup.py
                  code I use to implement the item by<br>
                  > > > >>item backup.<br>
                  > > > >You should start using GitHub like
                  the rest of us.<br>
                  > > > ><br>
                  > > ><br>
                  > > >
                  _______________________________________________<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>
                  > ><br>
                  > > --<br>
                  > > James Cameron<br>
                  > > <a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
                  > >
                  _______________________________________________<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>
                  > ><br>
                  > _______________________________________________<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>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </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></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<br clear="all"><br>-- <br></a><div class="gmail_signature"><a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank"></a><div dir="ltr"><a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">Unsung Heroes of OLPC, interviewed live @ </a><a href="http://unleashkids.org" target="_blank">http://unleashkids.org</a> !</div></div>
</div></div>
</div>