Hi,
I am having a bit of trouble distinguishing the jsieve API from its
implementation. It is my intention to document this project, but I find it more
difficult to understand than it ought to be because of this problem.
If the library is small enough and the integration simple enough, then perhaps
it really doesn’t matter. However, for somebody like me who wants to understand
the library, reducing the API surface area is really helpful. Honestly, I take
a glance at the code and it is not immediately obvious to me what this is
about, or how I could use it. I don’t want to have to spend too much time
trying to document it. This is way more difficult than it ought to be for such
a “simple” library. 😅
Perhaps if users only need to create an actual sieve filter an never interact
with the code, then maybe it doesn’t matter, but the library still needs to be
integrated somehow with a system. How the heck is that done?
My “dumb” understanding is that it is just an implementation of a spec [1]. So,
shouldn’t this library then just have an API that matches the spec, and then an
implementation against the API? (Indeed, likely the only, but it is still
usually worthwhile to have a clean separation between API and implementation. I
guess this would like be the reference implementation for the Java API.)
Is there anybody here who knows this library well who can comment and give me
some direction?
Refactor to better separate API from implementation to allow easier use of this
library?
— OR —
Don’t touch this! Leave as is because nobody needs to know anyway?
Cheers,
=David
[1] https://tools.ietf.org/html/rfc5228
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
