[standards-jig] JEP:0015 Account Transfer

Casey Crabb debug at nafai.dyndns.org
Wed Feb 6 01:45:03 UTC 2002


Sorry for the insane amount of quoting, but context certainly helps the
short responses...


> > Right now I think I would leave off transport handling and push that to
> > the future.
> 
> I think this may be the best.

Ok; putting off transport migration for now.
  
> >> I think that we should give the initiator feedback on the process.  Perhaps
> >> something along the lines of x:event?
> > 
> > Agreed. Feedback is definately good. What sort of feedback should be
> > given though, and at what point? For each user contacted and updated?
> > What part the of process its in?
> 
> I think so but in a summary.  Say sending an update once a day as long as
> updates occurred during that time period.  Otherwise someone with 1000
> roster items could be in for quite a bit of extra messages!

Would an account migration really take a day's worth of time? Sounds
strange that it would take so long.

> >> Synchronizing info on accounts will be tough.  There doesn't seem to be very
> >> many ways of doing this well without specifying a lot of behavior.  For
> >> example, what if the new server doesn't support private storage but there is
> >> ton of info on the old server with private storage data?
> >> 
> >> I realize that a lot of the value of the spec is in offloading these issues
> >> from the client.  However, many of these things, esp things like sync'ing
> >> private data may be better left to the client to handle...
> > 
> > What if the user uses different clients at different times?  If the
> > account is destroyed at the end of the process then they might lose all
> > that data the other client uses.
> 
> I had a similar thought.  Multiple resources multiplied over multiple
> accounts is a major problem.  Or the race/deadlock nightmare scenario of
> someone in the midst of an account transfer and another client logs into the
> old account and a different new account and requests a transfer... Or logs
> into the first new account then logs into a second new account and starts an
> account transfer while the original account transfer is still in progress...

Since the server is actually transferring the account it can simply deny
the second request with the error that one is already in progress.

 
> And what happens if you're in the middle of an account transfer and wish to
> abort (or are forced to for some reason)... Defining the state of things,
> backing out from the migrated roster moves, etc needs to be defined.  And
> I'm not sure it will be easy.

I would say that there should never be a case where the account transfer
would fail ungracefully. That said if a tertserver is unreachable it
simply informs the user that a particular contact was unable to be
reached and must be informed of the new account manually. 

Before the roster transfer begins oldserver and newserver should agree
that there is enough resources on newserver for the account to be
transferred. I'll add that into the protocol.

I'll just dictate that an account transfer can not be cancelled once
begun.  It'll continue to completion.  If you want to 'undo' the
transfer simply transfer back.

 
> Sorry, just playing devil's advocate here... ;)

devil's advocate is good. Helps iron things out.
 
> >> It is also unclear if the client must remain logged in to both accounts
> >> while the account transfer is occurring or if they only need to be logged in
> >> to initiate things then can log out.
> > 
> > I would assume they would remain logged into both clients, then be
> > kicked off the old client when the account transfer is done and the
> > account removed.
> 
> OK.  What happens if the client disconnects before the transfer is complete?
> Would that abort the transfer or have no effect?

No effect. The account would still be transferred.

> > How about something like this:
> > A capabilities discovery whereby the oldserver can ask the newserver
> > what it supports. This list can include private data limits, transports,
> > etc. Then this data is fed back to the user so they can see what can and
> > can't be transferred?  I think this might be the 'easy' way out of the
> > problems we've been encountering.
> 
> Right.  Well, you could use Jabber browse to do that... Of course, I don't
> think that browse is "core" jabber so there is a chance that browse is not
> supported on one of the servers.  However, this may be the cleanest way of
> handling things.

I'm not sure Jabber browse does everything this would require yet. I
need to get up to speed on Jabber browsing, and add it into my client.

> Sorry for being such a pain in the rear.
Thanks for being a pain in the rear :)

-Casey




More information about the Standards mailing list