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 have some methods unsupported. 2. Have common and advanced APIs. Common one can be supported by all clients, while advanced one (or ones) can be specific for a particular client.
2020-08-25 15:32 GMT+03:00, Alexey Kukushkin <kukushkinale...@gmail.com>: > 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 > ignite-core and ignite-client would both depend on ignite-api. I was told > on the design review it was not an appropriate moment to make such a > decision. (I still think a separate ignite-api.jar would be a good idea). > Then I implemented the thin client as a separate JAR having its own API. On > the code review I was told to merge the client into ignite-core but keep > the API separate. The motivation was there was too much unsupported > functionality in the thin client to implement the thick client API at that > moment. > > вт, 25 авг. 2020 г. в 00:13, Igor Sapego <isap...@apache.org>: > >> 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 <plehanov.a...@gmail.com> >> wrote: >> >> > 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 < >> > valentin.kuliche...@gmail.com>: >> > >> > > 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 >> > > <plehanov.a...@gmail.com >> > >> > > wrote: >> > > >> > > > 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 >> > > > these interfaces are fully independent. So we can't build common >> > > > abstraction which can work with ClientCache and IgniteCache without >> > code >> > > > duplication. For example, we have ignite-spring-data module, to >> > > > make >> it >> > > > thin-client compliant we should copy-paste all cache methods >> > invocations. >> > > > >> > > > It's impossible to make thin and thick interfaces absolutely >> identical >> > > and >> > > > we can't extend one from another since there thick and thin >> > > > specific >> > > > methods needed, but we can move common methods to the parent >> interface. >> > > But >> > > > here is another problem: exceptions. Thick methods declared as >> throwing >> > > > IgniteException and IgniteCheckedException, but all thin-client >> > > interfaces >> > > > use ClientException. Without common exceptions for thin and thick >> > > clients, >> > > > we can't build common parent interface. >> > > > >> > > > Currently, only a small amount of thick interfaces can be fully >> reused >> > by >> > > > thin-client (Queries, IgniteBinary, ClusterNode) >> > > > >> > > > Also, I would like to discuss JCache support by thin-client. We >> already >> > > use >> > > > some of JCache specification for thin-client, but not fully support >> > > JCache. >> > > > For example, we use Cache.Entry for queries and JCache expiration >> > > policies >> > > > in public thin-client API (also, some of JCache interfaces are used >> by >> > > the >> > > > internal implementation). >> > > > >> > > > I've tried to implement POC for continuous queries for java thin >> > client, >> > > > but without JCache support API looks weird. On the one hand, we >> should >> > > use >> > > > CacheEntryEventFilter (JCache interface) since it's required by the >> > > > server-side, on the other hand, we can't use >> CacheEntryUpdatedListener >> > > > since it requires CacheEntryEvent which requires an instance of >> > > > Cache >> > > > (JCache interface), which doesn't exist on the thin-client side. >> > > > >> > > > We have plans to change public API in Ignite 3.0, perhaps it makes >> > sense >> > > to >> > > > make thick and thin API consistent. WDYT? >> > > > What about JCache support by thin-client in Ignite 3.0? >> > > > Please, share your thoughts. >> > > > >> > > > [1]: >> > > > >> > > > >> > > >> > >> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-51-Java-Thin-Client-Async-API-td48900.html >> > > > >> > > >> > >> > > > -- > Best regards, > Alexey > -- Best regards, Ivan Pavlukhin
