Hi all,

I'm thinking about the possibility of making a "Geode public API" module,
mostly containing interfaces that Geode implements.

Why would one do this, you may ask? Here are some reasons.

* It makes clear what is our public API (as opposed to "internal" type
packages).
* Users only have to compile against the API package.
* Avoiding cyclic dependencies for modules that are internal parts of Geode.

For cyclic dependencies, consider the case of the geode-protobuf module. It
needs to be able to perform operations on the Cache and Locator, which
means it needs to depend on geode-core. We can't have cyclic dependencies,
so we have to use a ServiceLoader to get the service in core, which feels
like a bit of a hack. If geode-core could depend on the geode-protobuf
module, we could have a tighter connection, and not have to worry (as we
currently do) that anything we expose must be visible from core.[1]

Using ServiceLoader this way feels like a hack, because it's not really
something that we would expect a user to provide a service for, and we
can't handle the presence of more than one service. [2]

Maybe there's a better way to do this. Maybe Java 9 packages can make it
nicer. Maybe the ServiceLoader can be done better.

I'd like to solicit comment from the devs. What are your thoughts? What's
the best way to handle this? There are (AFAIK big, unanswered) questions
about how to handle varying levels of public vs. internal API [3]. Do you
have any answers?

Thanks,
Galen


[1] as an aside, it's actually kind of nice to have everything hidden from
core. It's resulted in an interface that creates an opaque object to manage
connection state, with a single `processMessage` method on it.
Nevertheless, other modules may with to expose more, and using
ServiceLoader feels like a hack.

[2] Actually, we do have to handle this case, and it's hard to do right,
because we have to blow up (abort the caller, throw a RuntimeException) or
ignore it and try to carry on (by closing connections made with the new
protocol). Blowing up breaks tests in geode-core, so we log a message, but
this maybe makes it easier to start up an incomplete cache....

[3] Maybe we could have multiple packages, one stable for public API, one
internal (and potentially unstable) for things that are shared between
modules?

Reply via email to