<div>Hello Bill,<br></div><div><br></div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If my vote counts, I&#39;ll +1 as well.  In the XO case, it should work<br>
the same as before.  In the non-XO, it tries to do something useful<br>
rather then nothing.<br></blockquote><div><br></div><div>Thanks ! :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
However, I have some concerns/questions:<br>
<br>
1.  In the non-XO case, why do you replace the files which contain<br>
previously generated uuid/sn/backup_url rather then using them as is?<br></blockquote><div><br></div><div>I&#39;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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
2. The XO always uses a static &quot;schoolserver&quot; URL to register while a<br>
non-XO will use it&#39;s jabber server instead.  For minimum impact on<br>
current XO usage, I understand this.  Going forward, I think this<br>
inconsistent behavior will be a problem.  I believe there are already<br>
deployments using both XO&#39;s and SoaS based systems.  At a minimum, I<br>
would suggest creating a bug ticket for this inconsistency so it can<br>
be dealt with correctly in a later release.<br></blockquote><div><br></div><div>Yeah I suppose it is a problem in cases where the jabber server and registration server are not the same machine. </div></div>