[IAEP] [Sugar-devel] Request Feature Freeze Exception for ticket #916 to allow sugar on non-xo hardware to register with a schoolserver

[Tomeu Vizoso]

On Sat, Sep 5, 2009 at 00:00, Bill Bogstad<bogstad at pobox.com> wrote:
> On Fri, Sep 4, 2009 at 10:43 AM, Hamilton Chua<hamilton.chua at gmail.com> wrote:
>> Hello Bill,
>>
>>> If my vote counts, I'll +1 as well.  In the XO case, it should work
>>> the same as before.  In the non-XO, it tries to do something useful
>>> rather then nothing.
>>
>> Thanks ! :-)
>>
>>>
>>> However, I have some concerns/questions:
>>>
>>> 1.  In the non-XO case, why do you replace the files which contain
>>> previously generated uuid/sn/backup_url rather then using them as is?
>>
>> I'm not sure I understand. On non-XO hardware, there is no UUID and SN to
>> begin with, both have to be generated when Register is clicked. The
>> backup_url is the registration server or in the case of non-xo hardware the
>> jabber server.
>
> I understand that non-XO hardware doesn't come with a UUID and SN.
> You have defined a way of
> providing this information (which could be used in the future for any
> other purpose that requires unique
> ids in a Sugar environment).  The problem I have is that if something
> has already created those files, you delete the files and start over.
>  Looking forward to multiple possible users of unique ids for Sugar
> installations, this would appear to be wrong.  Instead of deleting the
> files, use the values that are already there.  Under what
> circumstances would those files already exist if their contents were
> wrong?
>
> If someone moves between locations, it would be nice to be able to
> register (backup) in multiple places.  Your code
> would have to be changed to allow this.  (I'm sure there would be
> other changes needed as well, but this restriction seems
> unnecessary to me.)
>
>>
>>>
>>> 2. The XO always uses a static "schoolserver" URL to register while a
>>> non-XO will use it's jabber server instead.  For minimum impact on
>>> current XO usage, I understand this.  Going forward, I think this
>>> inconsistent behavior will be a problem.  I believe there are already
>>> deployments using both XO's and SoaS based systems.  At a minimum, I
>>> would suggest creating a bug ticket for this inconsistency so it can
>>> be dealt with correctly in a later release.
>>
>> Yeah I suppose it is a problem in cases where the jabber server and
>> registration server are not the same machine.
>
> Yeah, and it's not always 'schoolserver'.    The scenario is people
> staring with SoaS (sticks are cheap) and then acquiring some XOs
> (hardcoded to schoolserver).    A long term issue that I have with how
> the XS integrates with Sugar is it's desire for total control over the
> namespace and static use of 'schoolserver' to find things.   The Sugar
> UI has been modified to allow other jabber servers.  Why not make that
> true for all services?  Splitting service functions (as you suggest)
> makes this even more
> of an issue.  I don't think the whole question of how XOs/Sugar find
> things has really been thought through as well as it should.
> It feels very brittle to me.

I agree that what we have now is a bit primitive, but I would prefer
if we started with these simple solutions at first and then improve
after getting feedback.

AFAIK this patch provides a feature that is being needed by deployments today.

We have already some tickets from deployments in the bugtracker about
improvements in this area, we need people to give them some thought
and propose further improvements.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning