Methods on IXmlRepository should be async

aspnet / DataProtection

[Archived] Data Protection APIs for protecting and unprotecting data. Project moved to https://github.com/aspnet/AspNetCore

Apache License 2.0

130 stars 87 forks source link

Methods on IXmlRepository should be async #124

Closed sunsided closed 8 years ago

sunsided commented 8 years ago

Apart from the documentation being a bit thin on IXmlRepository, the methods really should be async.

Considering it's a repository that very likely has something to do with physical storage - which usually blocks - there should be a "native" way to use await within the implementation. I'm currently working on a MongoDB storage and have to resort to use blocking calls just to be able to use it as a repo. I'm pretty sure other implementations would benefit from that as well.

sunsided commented 8 years ago

Might be related to #37.

muratg commented 8 years ago

@GrabYourPitchforks do you remember why we didn't make the methods async here?

Eilon commented 8 years ago

Though this might be nice, the data protection stack is non-async all the way around, so it would be infeasible to make just this one API be async. A proper fix would involve changing many, many APIs, and there isn't time for that to happen.

niemyjski commented 6 years ago

This should be revisited. The only data store that isn't async is an in memory implementation...

GrabYourPitchforks commented 6 years ago

FWIW I'm not opposed to making the repository APIs async. However, we need to be mindful of the fact that the caller is still always going to be sync. This implies that the conversation should focus solely on "what can we do to make it easier to write a custom repository?" rather than "how do we prevent a thread from being blocked?"

niemyjski commented 6 years ago

I'm thinking the underlying implementation should take care of it and it should be really easy to implement. I've looked at many implementations while implementing a Foundatio IFileStorage version... They all do crazy things and are not uniform on how they:

Are executed (sync, async, configureawait(false) / Blocking with .Result, or even exponential backoffs...).
Should XElements be stored in a single file or multiple on disk.
Should the friendlyName be the file path (when isn't it set to a unique value..)
Should the element be loaded from a stream or string and with what validation methods or apis.
Should Gets and Saves be retried.
Concurrency options, should I be locking?
How are saved files cleaned up in case of disk storage..

It's really not intuitive.