[bis] Fix misimport of ktor variable in common module

[ArnyminerZ]

• Fixed usages of HttpHeaders: created our own HTTP headers constants file.
• Annotated all functions from common code that use ktor with @UsesKtor:
  • Basically we are only using ContentType, but it's a bit too complex to implement it on our own, so at least annotate it.

[rfc2822]

I'm not a fan of having a manually maintained annotation for Ktor dependencies. It looks error-prone and if we just forget a single thing (or forget to not use such annotated methods in DAVx5 code), everything breaks.

So considering that we want to transition to Ktor anyway, I think we can keep the ktor code for simplicity and just not exclude the ktor library in DAVx5.

And then hopefully make progress to move everything to ktor …

[ArnyminerZ]

I'm not a fan of having a manually maintained annotation for Ktor dependencies. It looks error-prone and if we just forget a single thing (or forget to not use such annotated methods in DAVx5 code), everything breaks.

Maybe we just specify it in the comments? To be sure. Because with other functions it's clear (for example, they use a ktor reference in the arguments), but for others (such as they use ContentType), it's not clear from the caller side.

[rfc2822]

Maybe we just specify it in the comments? To be sure. Because with other functions it's clear (for example, they use a ktor reference in the arguments), but for others (such as they use ContentType), it's not clear from the caller side.

However we'd then have to remove it again when we drop okhttp …

I think we should keep ktor usage in common code as little as possible, but it's acceptable. We just need to know that Ktor must not be excluded in gradle.

So maybe mention that in the README? That dav4jvm is currently in a rewrite phase to Ktor and that ktor must not be excluded. We can then update it when we remove okhttp from the dependencies.

[ArnyminerZ]

I've updated everything, and added a note to the README. Maybe the title of the PR should be updated now

[rfc2822]

I have added a comment to the Ktor issue: #72 (comment)

[rfc2822]

Nice. There are some references (especially in DavResource), we can replace them right now so that the new constants are actually used.

We can replace header names in other places whenever we change code in those places.

[ArnyminerZ]

we can replace them right now so that the new constants are actually used.

So we want to ignore completely that ktor's HttpHeaders exists, and use our own, right?

[rfc2822]

Ok now I'm confused, I thought ktor HttpHeaders is rather an internal class.

But it's part of the API, so we can of course use HttpHeaders everywhere, especially as we have given up the strict separation of okhttp and ktor.

So we won't need this class (HttpHeaderNames) at all because ktor HttpHeaders also defines ETag and ScheduleTag.