Whoops, good call!

good call

If this was named set_status, would that mean that calling it with TRAVERSITY_DISCOVERER_STATUS_DISCOVERING would start the process and then we remove traversity_discoverer_discover?
The reason I didn't name this set status was that the traversity_discoverer_discover and traversity_discoverer_discover_finished seem to pair better and that traversity_discoverer_discover_finish was less likely to be called by users of the library.

If this was named set_status, would that mean that calling it with TRAVERSITY_DISCOVERER_STATUS_DISCOVERING would start the process and then we remove traversity_discoverer_discover?


That would be confusing. But if the name stays traversity_discoverer_discover_finished shouldn't it either not be possible or at least produce a warning when calling it with TRAVERSITY_DISCOVERER_STATUS_DISCOVERING? Because in my mind it doesn't make sense to finish something with an "in progress status". You couldn't abuse the function in traversity_discoverer_discover then though...

We can add that check, it doesn't really matter the question is how should this API work.. We need to get that figured out so we can actually start progressing with this and sitting for 8+ days isn't something I was aiming for.

I agree we want to discourage users calling it, but it's weird to call it _finished when it's called multiple times to update progress. I guess partly I misread it as _finished when you intended _discover_finished as the verb. Perhaps something like tranversity_discoverer_update_status?

traversity_discoverer_update_status could work, but I'm wondering if we should just ditch _discover and have set_status do all the things, including calling the abstract method if the state is discovering.

I think it's fine to be separate. Might be confusing for users to mix both types of status 'setting'.

I actually left it as 2 separate methods in the most recent code update.