Yes! Do it! Even if it can’t be complete at this time because of strange dependencies we should start the effort.
You might just start with some common use APIs like listeners and functions. At least in that case if all your hat is going to reference is functions and listeners you don’t have to pull in Geode-core. -Jake > On Oct 11, 2017, at 5:49 PM, Galen O'Sullivan <gosulli...@apache.org> wrote: > > 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?
