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 <tony_ander...@usa.net> 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 <tony_ander...@usa.net>
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 <tony_ander...@usa.net>
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
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to