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

[Bill Bogstad]

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.

Bill Bogstad