Ivan, The list is not final, we can still discuss and add more points to be cleaned in 3.0. The more clear and understandable the API will be, the better. This thread was intended to draft the removal scope for 3.0 and to understand which portions will be definitely removed.
ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vololo...@gmail.com>: > 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, Павлухин Иван <vololo...@gmail.com>: > > > > 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 <dma...@apache.org>: > > > > > > 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 < > alexey.goncha...@gmail.com> > > > wrote: > > > > > > > Denis, > > > > > > > > Are we ready to present the list to the user list? > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dma...@apache.org>: > > > > > > > > > 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 <dpav...@apache.org> > > > > 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 <a...@apache.org>: > > > > > > > > > > > > > +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 < > dma...@apache.org> > > > > > 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 < > > > > > > > > alexey.goncha...@gmail.com> > > > > > > > > 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 < > a...@apache.org>: > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > alexey.goncha...@gmail.com> > > > > > > > > > > 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 < > > > > > > > > > > > dmitry.melnic...@nobitlost.com>: > > > > > > > > > > > > > > > > > > > > > > > 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 >
