+1 one for the first approach. The users will start with a documentation page where we can define in a table format the scope of supported APIs.
— Denis > On Sep 12, 2017, at 3:06 AM, Pavel Tupitsyn <ptupit...@apache.org> wrote: > > I prefer the first approach. > Users can easily switch to client mode, run their code and see what works > and what not. > > Second approach may require huge amount of refactoring to even try the > client mode. > And new users have to make a tough choice, because switching later is hard. > > > As a middle ground we can introduce a separate top-level interface, > IgniteClient, > but re-use other interfaces when possible. > > For example, first iteration of our thin client will likely include most > cache operations in 2.3, > so we can re-use IgniteCache interface. > But IgniteClient will only include getCache() and getBinary() methods. > > This way it is still reasonably easy for users to switch between APIs, > and Unsopported exceptions are kept to a minimum. > > Pavel > > On Tue, Sep 12, 2017 at 12:42 PM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > >> Igniters, >> >> We are developing new thin client. There are two approaches on how to >> design it's interfaces - either re-use existing Ignite interfaces, or >> define new. Both approaches has pros and cons >> >> *1) Re-use interfaces* >> This approach is used in Hazelcast. Both server and client share the same >> API. >> >> Pros: >> - excellent UX, switching from server to client is a matter of changing >> several lines of code >> Cons: >> - first versions of our client would have very limited API support, so >> users would have wrong impression that client is very rich, while in >> reality most methods will throw "UnsupportedOperationException". This is >> frustrating. >> - Client and server interfaces will be locked forever, which might not be >> appropriate in certain cases. E.g. thin client might decide to execute >> "ComputeTask" inside the cluster, but ComputeTasl is not Serializable, so >> it cannot be re-used. >> >> *2) Separate interfaces* >> E.g. we will have "IgniteCache" and "IgniteClientCache", "IgniteCompute" >> and "IgniteClientCompute", etc. >> >> Pros: >> - Only really supported stuff is exposed to API >> Cons: >> - Separate code for thin client and (server, thick client) modes >> >> I would definitely prefer the first approach with shared interfaces, but a >> lot "UnsupportedOperationException" in the first versions scares me. >> >> What do you think? >> >> Vladimir. >>
