ubuntu-accomplishments-contributors team mailing list archive

[Jono Bacon <jono@xxxxxxxxxx>]

Hi Folks,

Firstly, thanks for the input.

On 24 April 2012 04:30, Rafał Cieślak <rafalcieslak256@xxxxxxxxx> wrote:
> This leads me to conclusion that grouping accomplishments that are verified
> by an external server will always be unsure to work properly, because it's
> based on unsure assumptions. Does that mean that our current way of
> displaying unlock notifications makes no sense?
>
> Do notice that for an average user a situation where
> multiple accomplishments are achieved at once is vary rare, it happens to us
> a lot while testing, but that's not a common case, so I believe an elegant
> way of dealing with multiple trophies being verified in a shot time is
> definitely not a high priority feature.

I agree. In my mind the mistake we are making right now is that when
we run the next batch of scripts, we are treating it as a group with
functionality that relates to that group. My feeling is that we treat
each script independently and process it independently. That will give
us a slightly less grouped "you unlock X experience" but if that means
a user sees multiple unlocked messages, I don't see that as that big
of a deal.

> My suggestion is to abandon scriptrun_results etc. at all. It's only purpose
> is to display bubbles "you have unlocked ..." only once per group
> of simultaneously achieved accomplishments, which - as I hope to have proved
> above - is usually not a good idea, may lead to confusion and even display
> incorrect information.
> A much easier approach that would solve problems with scriptrunner's state
> is to calculate unlocks for each verified accomplishment independently.
> Using the same example as above, that would mean when A.asc arrives, we
> determine how many new accomplishments are unlocked (1), completelly
> ignoring the fact that scriptrunner has detected that B was also
> accomplished. We will display information about B unlocking 100 new
> accomplishments when we'll get B.asc, which may be soon after, a longer time
> after, or maybe never.

I entirely agree.

> This way we always display true information, based on what is verified by
> the server, and not just checked locally.
> Also, we do not have to worry about scriptrunner's state at all, it can even
> be running while we determine new, unlocked accomplishments. The whole
> process of unlocking anything is completely independent from scripts. Not to
> mention that this solution might slightly simplify the API a bit, as a
> side-effect.
> Another advantage is that daemon's behavior would then be a bit more
> predictable and logical - the algorithm becomes: when a .asc arrives, check
> if that particular accomplishments unlocks anything else, and if it
> does, immediately display a bubble, notifying the number of unlocks.
> Does that make sense?

This makes sense to me. So I guess the workflow would look like this:

 * Scriptrunner kicks off a new batch of scripts.
 * When a trophy arrives, we verify it and if it verifies we do a
check for all trophies it unlocked and display the bubble.

> Also I need to say that I am not against displaying grouped information,
> this in fact would look much nicer - but I am convinced that with our
> current system architecture this would be very wrong in most cases.

I agree.

> And finally concerning consumer-producer model - While this will not solve
> the problem with current race condition, this is a very elegant way of
> managing tasks for the scriptrunner - I believe this way it would be much
> easier to control it, and to maintain it's performance. If Jono agrees, I
> might try implementing that for 0.2 as a part of refined API.

I agree, lets focus on this in 0.2.

> I hope my points are clear and make some sense.

Absolutely, thanks, Rafał!

   Jono

-- 
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon