RE: [PATCH] service: Fix preferred service reordering on ready state - VAUTRIN Emmanuel (Canal Plus Prestataire)

From: "VAUTRIN Emmanuel (Canal Plus Prestataire)" <Emmanuel.VAUTRIN@cpexterne.org>
To: Jussi Laakkonen <jussi.laakkonen@jolla.com>,
	"connman@lists.linux.dev" <connman@lists.linux.dev>
Subject: RE: [PATCH] service: Fix preferred service reordering on ready state
Date: Thu, 17 Jun 2021 10:22:18 +0000	[thread overview]
Message-ID: <PR1PR02MB47943483C93F21149F412B96930E9@PR1PR02MB4794.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <ac94b39a-f446-0e0c-9f1c-5102aec815ba@jolla.com>

Hi Jussi,

> The thing is that I've been doing similar work on our fork and the end 
> result turned out to be fixing the sorting of the services.
Great.

> It does not anyways seem to be quite feasible to first let the sorting re-arrange 
> services, then with these changes make exceptions based on a specific 
> state, which then will change after the services are again sorted?
> I haven't submitted our changes to upstream just mainly because of 
> historic reasons there is a bit of a different approach in use with 
> service.c. This hopefully changes when there is time to check all things 
> and get the fork closer to upstream. Our for does involve a slightly 
> stricter approach [...]
> and the unit tests (that are not yet 100% complete) [...]
I have no opinion about that, my knowledge of this part is to light,
and I have just a limited time to spend on it. I let Daniel check this part.

> But since this is about allowing to follow the preferred technologies 
> list that is being set why not do it in the place where the list is 
> already utilized for sorting? I mean that as there is a clear reference 
> to prefer online over ready state so the preferred technologies list 
> should be as an exception in this regard.
> Your approach works but I'm not sure if there are some corner cases 
> induced by this approach. These are my notes on this matter, I hope you 
> consider this proposition.
As first step, I have just proposed a direct fix based on current implementation
(also fixing the service state update notification), in order to limit
regressions and quickly be integrated.
In my opinion, the second step will consist in a more consequent work,
based directly on the sorting itself, what Daniel has probably also started
by his side, but of course, I let him decide the best way to follow. If required,
I can try spending some time to test the final solution based on your both works.

Best Regards,

Emmanuel