JSR107 point - it is standard, it is always easy to refer to something user may already know.
BTW we have 1.0 in Ignite dependency, 1.1.1 recently released, maybe we should upgrade in 3.0. See also: https://mvnrepository.com/artifact/javax.cache/cache-api/1.1.1 ср, 17 июл. 2019 г. в 15:51, Vyacheslav Daradur <[email protected]>: > Ivan, > > * About Service Grid: > Yes, we discussed that old service grid implementation > (GridServiceProcessor) should be removed in 3.0, now it is marked as > obsolete. > This was in the list, maybe it was lost during formatting. > > Also, a class `ServiceConfiguration` should be moved to common package > of configurations: 'org.apache.ignite.configuration' it will bring to > change of API. > > * About JSR107: > I thought that JSR107 compliance is one of the advantages of Ignite, > at least in In-Memory mode. > I'm not sure why we should drop it. > > On Wed, Jul 17, 2019 at 3:26 PM Павлухин Иван <[email protected]> wrote: > > > > Also, I did not quite get the point about JSR107 (JCache). From time > > to time I see on user-list threads where Ignite is used along with > > Spring annotation-based cache integration. I suppose it requires > > JCache interfaces. What is crucially wrong with supporting it? > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <[email protected]>: > > > > > > Folks, > > > > > > Sorry if I am repeating something. I checked a page [1] and have not > > > found several items. > > > 1. I thought that there was an agreement of dropping OLD service grid, > > > was not it? > > > 2. Also IndexingSpi seems to me as a candidate for removal. > > > > > > Should I add those items to the page? Or is there another page > > > containing items to be removed that we agreed on? > > > > > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <[email protected]>: > > > > > > > > Alex, Igniters, sorry for a delay. Got swamped with other duties. > > > > > > > > Does it wait till the next week? I'll make sure to dedicate some > time for > > > > that. Or if we'd like to run faster then I'll appreciate if someone > else > > > > steps in and prepares a list this week. I'll help to review and > solidify it. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk < > [email protected]> > > > > wrote: > > > > > > > > > Denis, > > > > > > > > > > Are we ready to present the list to the user list? > > > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[email protected]>: > > > > > > > > > > > I wouldn't kick off dozens of voting discussions. Instead, the > content on > > > > > > the wiki page needs to be cleaned and rearranged. This will make > the > > > > > > content readable and comprehensible. I can do that. > > > > > > > > > > > > Next, let's ask the user community for an opinion. After > reviewing and > > > > > > incorporating the latter we can do one more dev list discussion > with the > > > > > > last call for opinions. Next, will be the voting time. If there > is a > > > > > > feature someone from the dev list is against of removing, then > we can > > > > > start > > > > > > a separate vote for it later. But let's get into those cases > first. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > I propose each removal should have separated formal vote > thread with > > > > > > > consensus approval (since it is code modification). > > > > > > > > > > > > > > This means a single binding objection with justification is a > blocker > > > > > for > > > > > > > removal. > > > > > > > > > > > > > > We need separation to let community members pick up an > interesting > > > > > topic > > > > > > > from email subject. Not all members reading carefully each > post in > > > > > > > mile-long threads. > > > > > > > > > > > > > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov <[email protected]>: > > > > > > > > > > > > > > > +1 to email survey with following types of votes > > > > > > > > - silence (agree with all proposed removals) > > > > > > > > - we have to keep XXX because ... > > > > > > > > > > > > > > > > As a result, will gain lists > > > > > > > > "to be removed" - no one objected > > > > > > > > "can be removed" - single objection > > > > > > > > "should be kept" - multi objections > > > > > > > > > > > > > > > > Denis or Dmitry Pavlov, could you please lead this thread? > > > > > > > > > > > > > > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda < > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > > > Alex, > > > > > > > > > > > > > > > > > > I would do an email survey to hear an opinion of why > someone > > > > > > believes a > > > > > > > > > feature A has to stay. It makes sense to ask about the > APIs to be > > > > > > > removed > > > > > > > > > as well as integrations to go out of community support [1] > in the > > > > > > same > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > Has everyone expressed an opinion? If yes, I can go ahead > and > > > > > format > > > > > > > the > > > > > > > > > wishlist page and make it structured for the user thread. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html > > > > > > > > > - > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk < > > > > > > > > > [email protected]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Anton, good point. > > > > > > > > > > > > > > > > > > > > Do you have any idea how we can keep track of the > voting? Should > > > > > we > > > > > > > > > launch > > > > > > > > > > a google survey or survey monkey? Voting by email? > > > > > > > > > > > > > > > > > > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov < > [email protected]>: > > > > > > > > > > > > > > > > > > > > > Alexey, > > > > > > > > > > > > > > > > > > > > > > Thank's for keeping an eye on page updates. > > > > > > > > > > > Near Caches is not a bad feature, but it should be > used with > > > > > > > caution. > > > > > > > > > > > At least we have to explain how it works on readme.io, > why and > > > > > > > when > > > > > > > > it > > > > > > > > > > > should be used because usage can drop the performance > instead > > > > > of > > > > > > > > > > increasing > > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > Anyway, I added near caches because I never heard > someone used > > > > > > them > > > > > > > > > > > meaningfully, not like a silver bullet. > > > > > > > > > > > So, that's just a proposal :) > > > > > > > > > > > > > > > > > > > > > > Also, I'd like to propose to have some voting about > full list > > > > > > later > > > > > > > > to > > > > > > > > > > gain > > > > > > > > > > > "must be removed", "can be removed" and "should be > kept" lists. > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk < > > > > > > > > > > > [email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Anton, > > > > > > > > > > > > > > > > > > > > > > > > I would like to pull-up the discussion regarding the > near > > > > > > caches > > > > > > > - > > > > > > > > I > > > > > > > > > > > cannot > > > > > > > > > > > > agree this is a feature that needs to be removed. > Near caches > > > > > > > > provide > > > > > > > > > > > > significant read performance improvements and, to > the best of > > > > > > my > > > > > > > > > > > knowledge, > > > > > > > > > > > > are used in several cases in production. Can you > elaborate on > > > > > > the > > > > > > > > > > > > shortcomings you faced? Maybe we can improve both > internal > > > > > code > > > > > > > and > > > > > > > > > > user > > > > > > > > > > > > experience? > > > > > > > > > > > > > > > > > > > > > > > > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk < > > > > > > > > > > > > [email protected]>: > > > > > > > > > > > > > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > As a Python thin client developer, I think that > separate > > > > > > > > repository > > > > > > > > > > is > > > > > > > > > > > > > a truly great idea! > > > > > > > > > > > > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov > wrote: > > > > > > > > > > > > > > - Move to separate repositories: thin clients > (at least > > > > > > > > non-Java > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ones) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best Regards, Vyacheslav D. >
