Hi Igniters,
Separate API module sounds nice to me as well. And I also think it is
fine that thin client does not support as much operations as client
node, because it is appealing to evolve API not strictly
synchronously. And I can imagine several options:
1. Have rich API with possibility to
I am wrong Alex but let me provide some history: when I originally
developed the Java thin client 3 years ago I suggested to take all public
API out of ignite-core.jar into a separate ignite-api.jar and develop Java
thin client implementing the common API from the ignite-api.jar. So the
Yes, it was an attempt to separate thick and thin clients as much as
possible
to move them in separate libs in future.
Alex, what do you think? What is the right path here from the Java
developer viewpoint?
Best Regards,
Igor
On Mon, Aug 24, 2020 at 9:40 AM Alex Plehanov
wrote:
> Hi Val,
>
>
Hi Val,
No, I don't know why ClientException was introduced. Perhaps it was an
attempt to strictly separate thin and thick implementations. But there
still some API and thick implementation reused in thin client
(BinaryObjects, Queries).
пт, 21 авг. 2020 г. в 23:28, Valentin Kulichenko <
Hi Alex,
Do you know if there is any particular reason why we introduced
the ClientException in the first place? Generally, I believe that
consistency is a good thing, but there might be something that we're
missing.
-Val
On Fri, Aug 21, 2020 at 2:33 AM Alex Plehanov
wrote:
> Hello, Igniters!
Hello, Igniters!
Since we touched on the subject of consistency across thin/thick APIs in
thread [1] I would like to continue the discussion here.
Currently, thick and thin APIs look similar but have no common parents. A
set of ClientCache methods is almost a subset of IgniteCache methods, but
