Re: [Sugar-devel] Sugar-On-The-Ground features

[Jerry Vonau]

Tony, my hosting service is suddenly on an RBL so my email is not making it
to the list could you reply to the list for my to keep the record in the
archives going please.  

> On May 17, 2016 at 9:20 AM Tony Anderson  wrote:
> 
> 
> Hi, Jerry
> 
> You raise some interesting points. Thanks for confirming that ejabberd 
> still requires registration.
> 
> How would an xo connect to different servers for backup and for 
> ejabberd? 

One might be inclined to alter the new values at image creation time, or
from the command prompt.

> What might be useful is that
> the client is automatically registered for ejabberd at connection but 
> only registered for backup at one machine.
> Currently this is done by showing the url in the network control panel 
> and allowing for it to be erased. Once erased,
> a new registration is possible. 

That is a bit of a flaw in that the code assumes 'schoolserver' is the
dns_name, that might not be the case when the 'schoolserver' is not the
gateway for any of the clients and nobody has or can't alter the dns
records for that LAN. 

> This could be used (with cleaned up UI) 
> so that the xo is registered to one server and connection
> to a different server would not result in backup.
> 

What really is required are different fields for registration, backup, and
collaboration in the UI with adjustments in the code to read/write the
values in the user fields. The default values could be part of the schema
that GTK/sugar uses, which should open up the door for the opportunity at a
better discovery of the registration service.


> My goal is to implement the OLE Nepal technique of automatically 
> registering the server at each connection. This could be arranged
> to register for ejabberd but only for backup if the client is not 
> registered for a different server. This could still have the user erase
> the
> name in the network control panel to force a new registration for backup.
> 

Might be more universal to have the registration service be advertised from
the 'schoolserver' via avahi on the local LAN and have the clients query
the LAN for the avahi machine name of the registration service being
offered, that will take hardcoding of the dns name right out of the
picture.

Jerry

> Tony
> 
> On 05/17/2016 03:53 PM, Jerry Vonau wrote:
> >
> >> On May 17, 2016 at 8:30 AM Tony Anderson 
> >> wrote:
> >>
> >>
> >> Hi, Jerry
> >>
> >> You want the url to be something like http://communityserver or
> >> http://server1? I think that should be easy to do.
> >>
> > User editable as to avoid messing with gconf or gsettings at the
> > command
> > prompt.
> >
> >> Wouldn't registration naturally use the hostname given at install
> >> time?
> >>
> > No, have a look at schoolserver.py, _REGISTER_URL is the starting point
> > default, that variable should be exposed to the UI.
> >
> >> Ds_backup uses the name from registration which is shown in the
> >> control
> >> panel
> >> network.
> >>
> > See above, jabber_server is set during registration, and that is really
> > intended for collaboration, thus it's more of a hack when backup is
> > referencing it, and should be exposed in the UI to split out the two
> > values. The backup and ejabberd servers don't have to be the same
> > machine
> > but the original XS makes the assumption that the services live on the
> > same
> > machine.
> >
> >> I was concerned you were wanting registration to be connected to
> >> Sugar's
> >> webservices which, as I understand it, are links to twitter, facebook
> >> and so on.
> >>
> > Just thinking where the best place to offer the user editable fields
> > could
> > live.
> >
> > Jerry
> >   
> >> Tony
> >>
> >> On 05/17/2016 02:47 PM, Jerry Vonau wrote:
> >>> Would be nice to be able to alter the url/dns_name of the server
> >>> machine
> >>> that is offering the backup from within the client as not to rely on
> >>> the
> >>> only hardcoded 'schoolserver' dns_name that registration provides. As
> >>> myself and others have said the original XS model wants to run
> >>> everything
> >>> and that my not always be possible resulting in client registration
> >>> that
> >>> can't resolve 'schoolserver' and breaking ds-backup.
> >>>
> >>> Is that clearer?
> >>>
> >>> Jerry
> >>>
>  On May 17, 2016 at 7:29 AM Tony Anderson 
>  wrote:
> 
> 
>  Hi, Jerry
> 
>  I am not sure how ds_backup is connected to webservices.
> 
>  Tony
> 
>  On 05/17/2016 02:15 PM, Jerry Vonau wrote:
> > Only once ds-backup-client is modified to fit into the webservices
> > framework and its settings can be viewed/modified from within
> > sugar-cp-backup or the webservices applet.
> >
> > Just my 'loonie's'[1] worth,
> >
> > Jerry
> >
> > 1. https://en.wikipedia.org/wiki/Loonie
> >
> >> On May 17, 2016 at 6:42 AM Tony Anderson 
> >> wrote:
> >>
> >>

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Jerry

You raise some interesting points. Thanks for confirming that ejabberd 
still requires registration.


How would an xo connect to different servers for backup and for 
ejabberd? What might be useful is that
the client is automatically registered for ejabberd at connection but 
only registered for backup at one machine.
Currently this is done by showing the url in the network control panel 
and allowing for it to be erased. Once erased,
a new registration is possible. This could be used (with cleaned up UI) 
so that the xo is registered to one server and connection

to a different server would not result in backup.

My goal is to implement the OLE Nepal technique of automatically 
registering the server at each connection. This could be arranged
to register for ejabberd but only for backup if the client is not 
registered for a different server. This could still have the user erase the

name in the network control panel to force a new registration for backup.

Tony

On 05/17/2016 03:53 PM, Jerry Vonau wrote:



On May 17, 2016 at 8:30 AM Tony Anderson  wrote:


Hi, Jerry

You want the url to be something like http://communityserver or
http://server1? I think that should be easy to do.


User editable as to avoid messing with gconf or gsettings at the command
prompt.


Wouldn't registration naturally use the hostname given at install time?


No, have a look at schoolserver.py, _REGISTER_URL is the starting point
default, that variable should be exposed to the UI.


Ds_backup uses the name from registration which is shown in the control
panel
network.


See above, jabber_server is set during registration, and that is really
intended for collaboration, thus it's more of a hack when backup is
referencing it, and should be exposed in the UI to split out the two
values. The backup and ejabberd servers don't have to be the same machine
but the original XS makes the assumption that the services live on the same
machine.


I was concerned you were wanting registration to be connected to Sugar's
webservices which, as I understand it, are links to twitter, facebook
and so on.


Just thinking where the best place to offer the user editable fields could
live.

Jerry
  

Tony

On 05/17/2016 02:47 PM, Jerry Vonau wrote:

Would be nice to be able to alter the url/dns_name of the server
machine
that is offering the backup from within the client as not to rely on
the
only hardcoded 'schoolserver' dns_name that registration provides. As
myself and others have said the original XS model wants to run
everything
and that my not always be possible resulting in client registration
that
can't resolve 'schoolserver' and breaking ds-backup.

Is that clearer?

Jerry


On May 17, 2016 at 7:29 AM Tony Anderson 
wrote:


Hi, Jerry

I am not sure how ds_backup is connected to webservices.

Tony

On 05/17/2016 02:15 PM, Jerry Vonau wrote:

Only once ds-backup-client is modified to fit into the webservices
framework and its settings can be viewed/modified from within
sugar-cp-backup or the webservices applet.

Just my 'loonie's'[1] worth,

Jerry

1. https://en.wikipedia.org/wiki/Loonie


On May 17, 2016 at 6:42 AM Tony Anderson 
wrote:


Hi, Sebastian

So what I assume James Cameron means when he says backup is not part
of
Sugar is that:

sugar-cp-backup-0.106.0-1.fc18.noarch

is and

ds-backup-client-0.106.0.1.fc18.noarch

is not.

Perhaps, the package should be renamed:

sugar-ds-backup-client-0.106.0.1.fc18.noarch

Tony

On 05/17/2016 12:52 PM, Sebastian Silva wrote:

El 17/05/16 a las 04:36, Tony Anderson escribió:

This 'OLPC OS' is a recent invention. I still consider what is
installed on an XO as Sugar (or a Fedora remix).

Tony,
Please don't use different terminology as everyone else.

If you please go into your XO and type `rpm -qa | grep sugar`
you'll
see
which sugar packages are installed in your XO.
These are the only "sugar" bits. The rest is OLPC OS, which is
based
in
Fedora. Use `rpm -qa | less` to see all packages including sugar
dependencies (e.g. BeautifulSoup, GTK, etc). A GNU/Linux
distribution
uses packages to upgrade components. Sugar is but one component
(consisiting of a few packages).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

.


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Jerry

You want the url to be something like http://communityserver or
http://server1? I think that should be easy to do.

Wouldn't registration naturally use the hostname given at install time?

Ds_backup uses the name from registration which is shown in the control 
panel

network.

I was concerned you were wanting registration to be connected to Sugar's
webservices which, as I understand it, are links to twitter, facebook 
and so on.


Tony

On 05/17/2016 02:47 PM, Jerry Vonau wrote:

Would be nice to be able to alter the url/dns_name of the server machine
that is offering the backup from within the client as not to rely on the
only hardcoded 'schoolserver' dns_name that registration provides. As
myself and others have said the original XS model wants to run everything
and that my not always be possible resulting in client registration that
can't resolve 'schoolserver' and breaking ds-backup.

Is that clearer?

Jerry


On May 17, 2016 at 7:29 AM Tony Anderson  wrote:


Hi, Jerry

I am not sure how ds_backup is connected to webservices.

Tony

On 05/17/2016 02:15 PM, Jerry Vonau wrote:

Only once ds-backup-client is modified to fit into the webservices
framework and its settings can be viewed/modified from within
sugar-cp-backup or the webservices applet.

Just my 'loonie's'[1] worth,

Jerry

1. https://en.wikipedia.org/wiki/Loonie


On May 17, 2016 at 6:42 AM Tony Anderson 
wrote:


Hi, Sebastian

So what I assume James Cameron means when he says backup is not part
of
Sugar is that:

sugar-cp-backup-0.106.0-1.fc18.noarch

is and

ds-backup-client-0.106.0.1.fc18.noarch

is not.

Perhaps, the package should be renamed:

sugar-ds-backup-client-0.106.0.1.fc18.noarch

Tony

On 05/17/2016 12:52 PM, Sebastian Silva wrote:

El 17/05/16 a las 04:36, Tony Anderson escribió:

This 'OLPC OS' is a recent invention. I still consider what is
installed on an XO as Sugar (or a Fedora remix).

Tony,
Please don't use different terminology as everyone else.

If you please go into your XO and type `rpm -qa | grep sugar` you'll
see
which sugar packages are installed in your XO.
These are the only "sugar" bits. The rest is OLPC OS, which is based
in
Fedora. Use `rpm -qa | less` to see all packages including sugar
dependencies (e.g. BeautifulSoup, GTK, etc). A GNU/Linux distribution
uses packages to upgrade components. Sugar is but one component
(consisiting of a few packages).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

.


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Jerry Vonau]

Would be nice to be able to alter the url/dns_name of the server machine
that is offering the backup from within the client as not to rely on the
only hardcoded 'schoolserver' dns_name that registration provides. As
myself and others have said the original XS model wants to run everything
and that my not always be possible resulting in client registration that
can't resolve 'schoolserver' and breaking ds-backup.

Is that clearer?

Jerry

> On May 17, 2016 at 7:29 AM Tony Anderson  wrote:
> 
> 
> Hi, Jerry
> 
> I am not sure how ds_backup is connected to webservices.
> 
> Tony
> 
> On 05/17/2016 02:15 PM, Jerry Vonau wrote:
> > Only once ds-backup-client is modified to fit into the webservices
> > framework and its settings can be viewed/modified from within
> > sugar-cp-backup or the webservices applet.
> >
> > Just my 'loonie's'[1] worth,
> >
> > Jerry
> >
> > 1. https://en.wikipedia.org/wiki/Loonie
> >
> >> On May 17, 2016 at 6:42 AM Tony Anderson 
> >> wrote:
> >>
> >>
> >> Hi, Sebastian
> >>
> >> So what I assume James Cameron means when he says backup is not part
> >> of
> >> Sugar is that:
> >>
> >> sugar-cp-backup-0.106.0-1.fc18.noarch
> >>
> >> is and
> >>
> >> ds-backup-client-0.106.0.1.fc18.noarch
> >>
> >> is not.
> >>
> >> Perhaps, the package should be renamed:
> >>
> >> sugar-ds-backup-client-0.106.0.1.fc18.noarch
> >>
> >> Tony
> >>
> >> On 05/17/2016 12:52 PM, Sebastian Silva wrote:
> >>> El 17/05/16 a las 04:36, Tony Anderson escribió:
>  This 'OLPC OS' is a recent invention. I still consider what is
>  installed on an XO as Sugar (or a Fedora remix).
> >>> Tony,
> >>> Please don't use different terminology as everyone else.
> >>>
> >>> If you please go into your XO and type `rpm -qa | grep sugar` you'll
> >>> see
> >>> which sugar packages are installed in your XO.
> >>> These are the only "sugar" bits. The rest is OLPC OS, which is based
> >>> in
> >>> Fedora. Use `rpm -qa | less` to see all packages including sugar
> >>> dependencies (e.g. BeautifulSoup, GTK, etc). A GNU/Linux distribution
> >>> uses packages to upgrade components. Sugar is but one component
> >>> (consisiting of a few packages).
> >>> ___
> >>> Sugar-devel mailing list
> >>> Sugar-devel@lists.sugarlabs.org
> >>> http://lists.sugarlabs.org/listinfo/sugar-devel
> >> ___
> >> Sugar-devel mailing list
> >> Sugar-devel@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> > .
> >
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Jerry

I am not sure how ds_backup is connected to webservices.

Tony

On 05/17/2016 02:15 PM, Jerry Vonau wrote:

Only once ds-backup-client is modified to fit into the webservices
framework and its settings can be viewed/modified from within
sugar-cp-backup or the webservices applet.

Just my 'loonie's'[1] worth,

Jerry

1. https://en.wikipedia.org/wiki/Loonie


On May 17, 2016 at 6:42 AM Tony Anderson  wrote:


Hi, Sebastian

So what I assume James Cameron means when he says backup is not part of
Sugar is that:

sugar-cp-backup-0.106.0-1.fc18.noarch

is and

ds-backup-client-0.106.0.1.fc18.noarch

is not.

Perhaps, the package should be renamed:

sugar-ds-backup-client-0.106.0.1.fc18.noarch

Tony

On 05/17/2016 12:52 PM, Sebastian Silva wrote:

El 17/05/16 a las 04:36, Tony Anderson escribió:

This 'OLPC OS' is a recent invention. I still consider what is
installed on an XO as Sugar (or a Fedora remix).

Tony,
Please don't use different terminology as everyone else.

If you please go into your XO and type `rpm -qa | grep sugar` you'll
see
which sugar packages are installed in your XO.
These are the only "sugar" bits. The rest is OLPC OS, which is based in
Fedora. Use `rpm -qa | less` to see all packages including sugar
dependencies (e.g. BeautifulSoup, GTK, etc). A GNU/Linux distribution
uses packages to upgrade components. Sugar is but one component
(consisiting of a few packages).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Jerry Vonau]

Only once ds-backup-client is modified to fit into the webservices
framework and its settings can be viewed/modified from within
sugar-cp-backup or the webservices applet. 

Just my 'loonie's'[1] worth,

Jerry  

1. https://en.wikipedia.org/wiki/Loonie

> On May 17, 2016 at 6:42 AM Tony Anderson  wrote:
> 
> 
> Hi, Sebastian
> 
> So what I assume James Cameron means when he says backup is not part of 
> Sugar is that:
> 
> sugar-cp-backup-0.106.0-1.fc18.noarch
> 
> is and
> 
> ds-backup-client-0.106.0.1.fc18.noarch
> 
> is not.
> 
> Perhaps, the package should be renamed:
> 
> sugar-ds-backup-client-0.106.0.1.fc18.noarch
> 
> Tony
> 
> On 05/17/2016 12:52 PM, Sebastian Silva wrote:
> >
> > El 17/05/16 a las 04:36, Tony Anderson escribió:
> >> This 'OLPC OS' is a recent invention. I still consider what is
> >> installed on an XO as Sugar (or a Fedora remix).
> > Tony,
> > Please don't use different terminology as everyone else.
> >
> > If you please go into your XO and type `rpm -qa | grep sugar` you'll
> > see
> > which sugar packages are installed in your XO.
> > These are the only "sugar" bits. The rest is OLPC OS, which is based in
> > Fedora. Use `rpm -qa | less` to see all packages including sugar
> > dependencies (e.g. BeautifulSoup, GTK, etc). A GNU/Linux distribution
> > uses packages to upgrade components. Sugar is but one component
> > (consisiting of a few packages).
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Sebastian

So what I assume James Cameron means when he says backup is not part of 
Sugar is that:


sugar-cp-backup-0.106.0-1.fc18.noarch

is and

ds-backup-client-0.106.0.1.fc18.noarch

is not.

Perhaps, the package should be renamed:

sugar-ds-backup-client-0.106.0.1.fc18.noarch

Tony

On 05/17/2016 12:52 PM, Sebastian Silva wrote:


El 17/05/16 a las 04:36, Tony Anderson escribió:

This 'OLPC OS' is a recent invention. I still consider what is
installed on an XO as Sugar (or a Fedora remix).

Tony,
Please don't use different terminology as everyone else.

If you please go into your XO and type `rpm -qa | grep sugar` you'll see
which sugar packages are installed in your XO.
These are the only "sugar" bits. The rest is OLPC OS, which is based in
Fedora. Use `rpm -qa | less` to see all packages including sugar
dependencies (e.g. BeautifulSoup, GTK, etc). A GNU/Linux distribution
uses packages to upgrade components. Sugar is but one component
(consisiting of a few packages).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Sebastian Silva]

El 17/05/16 a las 04:36, Tony Anderson escribió:
> This 'OLPC OS' is a recent invention. I still consider what is
> installed on an XO as Sugar (or a Fedora remix). 
Tony,
Please don't use different terminology as everyone else.

If you please go into your XO and type `rpm -qa | grep sugar` you'll see
which sugar packages are installed in your XO.
These are the only "sugar" bits. The rest is OLPC OS, which is based in
Fedora. Use `rpm -qa | less` to see all packages including sugar
dependencies (e.g. BeautifulSoup, GTK, etc). A GNU/Linux distribution
uses packages to upgrade components. Sugar is but one component
(consisiting of a few packages).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Sebastian

Exactly.

Tony

On 05/17/2016 11:00 AM, Sebastian Silva wrote:


El 17/05/16 a las 01:52, Tony Anderson escribió:

As always a good programmer implements a feature and makes it
available for
use. If it is a good design it will be adopted.

In contributing to a free software project, a good contributor will
update the feature until it is adopted. I have made the mistake in the
past of assuming that simply making something available would be enough.
Currently the way to do this is to make a pull request and respond to
every objection raised.
.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Sebastian

Agreed. This includes the screenshot feature as well.

Tony

On 05/17/2016 11:02 AM, Sebastian Silva wrote:


El 17/05/16 a las 01:33, Tony Anderson escribió:

The home view
implementation suffers heavily from the default naming in the Journal
which the 'save as' feature
addresses.

I agree here, let's land the save as feature first then. :-)
.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Sebastian

It is not a hack - it has been part of Sugar since 0.84 (before there 
was even a remix and before there were git repositories). AFAIK, it has 
not been
updated in years. This 'OLPC OS' is a recent invention. I still consider 
what is installed on an XO as Sugar (or a Fedora remix).


Tony

On 05/17/2016 11:01 AM, Sebastian Silva wrote:


El 17/05/16 a las 01:45, Tony Anderson escribió:

If you want an rsync solution, that is what is currently implemented
in Sugar (although
James Cameron claims this is not part of Sugar). It is distributed in
the 13.2.5 release.

As far as I understand, that is a hack, and not part of Sugar. For it to
be a part of sugar, it would have to be in the Sugar git repositories.
.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Sebastian Silva]

El 17/05/16 a las 01:33, Tony Anderson escribió:
> The home view
> implementation suffers heavily from the default naming in the Journal
> which the 'save as' feature
> addresses.
I agree here, let's land the save as feature first then. :-)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Sebastian Silva]

El 17/05/16 a las 01:45, Tony Anderson escribió:
> If you want an rsync solution, that is what is currently implemented
> in Sugar (although
> James Cameron claims this is not part of Sugar). It is distributed in
> the 13.2.5 release. 
As far as I understand, that is a hack, and not part of Sugar. For it to
be a part of sugar, it would have to be in the Sugar git repositories.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Sebastian Silva]

El 17/05/16 a las 01:52, Tony Anderson escribió:
> As always a good programmer implements a feature and makes it
> available for
> use. If it is a good design it will be adopted.
In contributing to a free software project, a good contributor will
update the feature until it is adopted. I have made the mistake in the
past of assuming that simply making something available would be enough.
Currently the way to do this is to make a pull request and respond to
every objection raised.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Sebastian

As always a good programmer implements a feature and makes it available for
use. If it is a good design it will be adopted. If not, the community 
will be more aware

of the opportunity and may come up with a more successful approach.

It is very easy to discuss a new feature and so kill it in indecision. I 
fear this may
happen with the font editor project trying to decide between javascript 
and python.


Tony

On 05/17/2016 07:50 AM, Sebastian Silva wrote:

My concern is that these features are rather simple to implement, but
hard to decide on. A medium-experienced python programmer might do each
in a couple of days. Utkarsh is a fine programmer so we should have him
do something significant with real impact, and avoid design deadlocks.


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Sebastian

I assume you mean you have not tried the feature. It is implemented by
Sugar but is, of course, meaningless without a server.

I am not sure what you mean by generalized. Registration establishes the
directory on the server for the rsync backup and creates a 
public/private key
to authenticate backups. I don't know the current implementation but as 
some point

registration was needed for ejabberd to support collaboration.

Tony

On 05/17/2016 07:50 AM, Sebastian Silva wrote:

>The keys are handled by registration. No change is intended. Rsync is
>the current backup scheme but it is not appropriate to the
>requirement. The wiki describes the intent of the change in detail.
>AFIK, there is no more requirement for local administration than is
>required by the current system.

I've personally never seen registration feature work. I'd be thrilled if
it could be generalized, or broken out into a standard package that
could be distribute


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi, Sebastian

The design assumption is a server using xsce6 (CentOS). Naturally, there 
are
many ways to build a LAMP stack and large deployments such as Uruguay, 
Peru,

and others may have their own solution (e.g. Rwanda has its own as well).

What I said was that Sugar and the school server form a system and, for 
best
effect, must be designed to work together. Martin Langhoff designed such 
a system
but the Sugar developers did not take advantage of the capability. I am 
certainly not saying

that a Sugar deployment is not free to design their own.

If you want an rsync solution, that is what is currently implemented in 
Sugar (although
James Cameron claims this is not part of Sugar). It is distributed in 
the 13.2.5 release.


Remember, Sugar was intended to support deployment of OLPC where it was 
reasonable to
expect that there were no other computers in the area and that a 
deployment would have at

most one server.

Tony

On 05/17/2016 07:50 AM, Sebastian Silva wrote:

The combination of a school server and Sugar is a system in which both
>parts must work together. As I understand it there are
>three environments for Sugar: standalone, with an active internet
>connection, and with a school server and no or limited internet access.
>The Sugar on the Ground is intended to support the third environment.

Your assumption is wrong, in that not everyone will use the same flavour
of server. In Perú, some will use the Ministry's PeruEduca distro,
others will use some Ubuntu flavour, or who knows what else. None use
the xs schoolserver as prepared by this community. Same thing for
Argentina, where Huayra GNU/Linux includes some parts of Sugar and have
their own server solution. You can't assume a homogeneous network or
that you will have the luxury of dictating how the server is configured,
but you might assume most if not all will have ssh+rsync. These are not
small deployments either.

>Originally, OLPC deployment was standalone with a laptop-laptop
>network for collaboration. However, it was realized that much more
>could be done in a deployment with a school server to provide access
>to some of the content available on the internet. Unfortunately Sugar
>did not work closely with Martin Langhoff to make for a
>well-integrated system.

It was actually Mr. Langhoff who did not develop standard solutions that
could be upstreamable into standard GNU/Linux distributions and worked
with assumptions such as the schoolserver being the only server in the
network etc. We should not make the same mistake.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Hi Sebastian,

Manash is implementing this feature.

Tony

On 05/17/2016 07:50 AM, Sebastian Silva wrote:

>The design discussion on the backup is at
>https://wiki.sugarlabs.org/go/Sugar-server_Journal_backup.

So who will work on this, Utkarsh or Manash?


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar-On-The-Ground features

[Tony Anderson]

Sebastian

I think we are discussing too many independent issues together.

I overstated the 'reverse'. I believe Sugar can still be distributed 
with a default of
'resume' from the home view. However, a gsetting configuration could 
allow deployments

and users to select the resume new as default.

The resume feature is essential but is available in a natural way in the 
Journal. The home view
implementation suffers heavily from the default naming in the Journal 
which the 'save as' feature
addresses. Now when you open the list of resume options on the home view 
you only now the sequence

of objects - not what document is involved.

Yes, users know how to cope with the feature. However, originally 
neither the palette nor the alt key was needed since
clicking on the icon launched the activity. This was one of the human 
interface virtues of Sugar.


Tony

On 05/17/2016 07:50 AM, Sebastian Silva wrote:

The home view patch is intended to 'reverse' that decision. The
>original idea that activities start new from the home view and are
>resumed from the Journal is clear and easy to understand. In many
>classrooms, users are surprised when they launch an activity and find
>it not at the main screen but in the middle of some other person's
>work. I have had teachers ask students to launch Browse only to have
>some embarassed when it plays music.

Those are valid concerns. While dogfooding (using Sugar myself), I found
resume-by-default quite handy. I've also observed teachers in the ground
knowing to clic "Start New" (but never the shift-key undiscoverable
shortcut).

I would like to ask the "soporte-digete" list which holds some 400
teacher-trainers from Peru for their opinion and I'll get back to you.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel