Add cancellation support on http feature sources

[navispatial]

Feature sources are created by GeoJSONFeatures.http and OGCAPIFeatures.http.

Add cancellation support with default logic and parametrization on these initializations.

It seems that currently the http package used by features sources does not support cancel tokens (as for example the dio package would support). See the issue Design an API to support aborting requests #424 of the http package. There exists a fork called cancellation_token_http.

The API for cancellation support could also utilize CancelableOperation from the async package.

See also #166 as a related enhancement suggestion.

[navispatial]

The cancellation_token_http package has nice examples, for example this one (same token for http access and parsing a response after it):

import 'package:cancellation_token/cancellation_token.dart';
import 'package:cancellation_token_http/http.dart' as http;

Future<void> makeRequest() async {
  var token = CancellationToken();
  try {
    var response = await http.get(
      Uri.parse('https://example.com/bigjson'),
      cancellationToken: token,
    );
    var parsedResponse = cancellableCompute(
      _readAndParseJson,
      response.body,
      token,
    );
    print('Request and parse complete');
  } on CancelledException {
    // If `token.cancel()` is called, the request and response parsing will be
    // cancelled and a CancelledException will be thrown
    print('Request and parse cancelled');
  }
}

Related cancellation_token package supports using same token for multiple cancelable computations.

Advantages of using this approach:

• async API requests could still return simply Future instead of CancelableOperation => same api for non-cancelable and cancelable requests, token would be an optional parameter
• using same token for multiple cancelable computations

Questions:

• this is not standard http or async package feature

[navispatial]

Considering a simple solution that would not expose any new dependencies on http feature source callers.

Currently for example an OGC API Features service is accessed by the geodata package like this:

// create an OGC API Features client for some service as `OGCFeatureService`
final client = OGCAPIFeatures.http(endpoint: Uri.parse('...'));

// get a feature source (`OGCFeatureSource`) for some collection the service behind client provides
final source = await client.collection('some_collection_name');

// `itemsAll` lets access all features on source (optionally limited by limit)
final itemsAll = await source.itemsAll(limit: 100);

// then use those items

This would be changed so that a client instance would internally share a cancelation token.

The OGCFeatureService class would have a method

/// Cancel any active asynchronous computation called on this client.
void cancelAll();

Calling cancelAll() would call cancel() on that internal token.

Internal implementation would use cancellation_token and cancellation_token_http packages, but without exposing classes or definitions by them to geodata users.

This solution would not be perfect. Cancelation would be tied to a client instance, so in some uses different instances would be needed if cancelation should not cancel all requests called on a client.

Alternatively cancelAll could be defined on a feature source (of a collection) in OGCFeatureSource class or it's super class.

[navispatial]

Do not want to add extra dependencies as using cancellation_token or cancellation_token_http packages would require.

On geodata versions 1.x.0 sticking on the standard http package. At least retries are possible as mentioned on #166.

So closing this now.

Maybe this could be reconsidered when planning geodata 2.x in the future. Then it should be a design choice which http library to use, http, dio or something else..