From impls for errors generally just take some error type and map
it into a variant of some podcast error enum. This removes the duplicate
impls by using a pattern macro to make the impls from the type of the
enum, the given error type, and the desired enum variant.
If you added a Feed where a Show exists but it had no episodes
entries, the stack would end up in a populated state, but the
HomeView would be blank without widgets.
This changes it so the stack state depends upon the episodes
table being populated instead of the show. The downside
is that if your only feed is one without episodes you can
no longer navigate and interact with it.
Stream::for_each terminated the stream upon the first error. This
was causing feeds to not update if any one returned a non-200ish
result. To work around this, we create a succesfull result for
every entry regardless at the end.
While we are at it, aslo switch from FuturesOrdered stream
to FuturesUnordered. There is no reason to use Ordered, this was
a typo initially.
Use the proper Stream API to return a future to run on the
executor. Previously I was using a workaround to convert the
Stream into a future and run it to completion in the Executor,
since I was not aware of a better API.
This commit add a new DataError Variant for feeds that return 304.
Its expected behaviror and the current API of Source::into_feed
is kinda limiting the return type to make it easier to handle.
Up till now 304 was returning an Error to early return. Ideally
Source::into_feed will return a Multi variant Result Enum.
example:
enum FeedResult {
Ok(Success(feed)),
Ok(NotModified),
Err(err),
}
Hopefully in a refactor in the near Future™
Till then we will just have to match and ignore
DataError::FeedNotModified.
This reverts commit e64883eecb
and 40dd2d6923
Seems like core.run() returns once its done even if there
are still tasks in the Runtime underneath. A way to solve that
would be to call the shutdown_on_idle method.
We need ownership of the threadpool in order to invoke
`shutdown_on_idle` method but core.runtime only returns a
referrence so we need to create our own threadpool.
This requires a RUSTFLAG to be set before hand for rayon to build.
This brakes a lot of tools like rls and clippy by default and
require special configs for itnegration.
Additionally, rayon_futures is still 0.1 and not much work seem
to have gone into it. Ideally it should be replased with the tokio
runtime/threadpool.
Additionally clear the Etags if the returned code is not 200 or 304.
Just to be extra safe. This is not as clean as it should, as this is
a temporary workaround until the API is reworked.
Related to #64
