ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: New thin client and interfaces/facades
Date Tue, 12 Sep 2017 21:17:17 GMT

I disagree. We already have client mode which support the full Ignite API.

Here we are talking about the new client binary protocol. To my knowledge,
the following APIs can be implemented over the new binary protocol:

- .NET Thin

All these protocols are already custom APIs. I would not migrate any other
existing clients to the new binary protocol, unless we see possible use
cases for it.

I am for the 2nd approach, where every implementation of some API over the
client binary protocol is custom to some use case.


On Tue, Sep 12, 2017 at 2:42 AM, Vladimir Ozerov <vozerov@gridgain.com>

> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message