[email protected] wrote:
If we only run the test once and let the caller catch the exception from
the portal test in the implicit case, then the test won't get run again.
If the test failed and the client then attempts an operation that needs
to get data, but the network is unavailable or misconfigured, it will
try its hardest to contact the hosts, because it thinks they're
available.
Unless I've missed an option, we have the following alternatives:
1. Only run the test in cases where we care about its success / failure.
We wouldn't do this for implicit refresh or sending intent data.
2. Leave it as it is now. Operations that are strictly informational
don't run the test, but operations that retrieve data run the test.
(Refresh yes, intent no).
3. Save the exception that's generated when the test fails. In the
current implementation, subsequent calls to capitve_portal_test() return
without performing the test. Instead of this behavior, check if the
test previously failed, if so, re-raise the previous exception. This
handles the case where the test fails but a caller caught the exception
and didn't do anything. I don't like this approach because we're
continuing to raise an error, and don't have a legitimate recovery
mechansim for the client.
In my previous e-mail, I was suggesting that #1 might be feasibile, but
if I've understood you correctly, you're not so keen on this approach?
As you previously pointed out, the downside to #1 is that it requires
that the client be aware of an implementation detail of transport
behaviour. That's the only aspect in particular that doesn't feel quite
right.
With that said, if we instead created a generic "transport_check" call
that callers could call at any time or optionally control for certain
operations, that seems alright. It seems like it just semantics, but I
think defining it as a "transport check" instead of a "captive portal
test" allows the transport system to get away with completely changing
what the definition of it is later without exposing the specifics of the
implementation.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
