[DISCUSSION] Ignite 3.0 and to be removed list

[Ivan Pavlukhin]

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 <[hidden email]>:

>
> 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 <[hidden email]>
> wrote:
>
> > Denis,
> >
> > Are we ready to present the list to the user list?
> >
> > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > > >
> > > > > +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 <[hidden email]>
> > > 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 <
> > > > > > [hidden email]>
> > > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > > [hidden email]>:
> > > > > > > > >
> > > > > > > > > > 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

[Ivan Pavlukhin]

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, Павлухин Иван <[hidden email]>:

>
> 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 <[hidden email]>:
> >
> > 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 <[hidden email]>
> > wrote:
> >
> > > Denis,
> > >
> > > Are we ready to present the list to the user list?
> > >
> > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > >
> > > > 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 <[hidden email]>
> > > 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 <[hidden email]>:
> > > > >
> > > > > > +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 <[hidden email]>
> > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > 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 <[hidden email]>:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>:
> > > > > > > > > >
> > > > > > > > > > > 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

[daradurvs]

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 Павлухин Иван <[hidden email]> 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, Павлухин Иван <[hidden email]>:
> >
> > 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 <[hidden email]>:
> > >
> > > 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 <[hidden email]>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Are we ready to present the list to the user list?
> > > >
> > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>
> > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > +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 <[hidden email]>
> > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > 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 <[hidden email]>:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>:
> > > > > > > > > > >
> > > > > > > > > > > > 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.

[Dmitry Pavlov]

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 <[hidden email]>:

> 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 Павлухин Иван <[hidden email]> 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, Павлухин Иван <[hidden email]>:
> > >
> > > 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 <[hidden email]>:
> > > >
> > > > 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 <
> [hidden email]>
> > > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > Are we ready to present the list to the user list?
> > > > >
> > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > > > >
> > > > > > 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 <
> [hidden email]>
> > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > > +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 <
> [hidden email]>
> > > > > > 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 <
> > > > > > > > > [hidden email]>
> > > > > > > > > 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 <
> [hidden email]>:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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.
>

[Alexey Goncharuk]

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, Павлухин Иван <[hidden email]>:

> 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, Павлухин Иван <[hidden email]>:
> >
> > 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 <[hidden email]>:
> > >
> > > 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 <
> [hidden email]>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Are we ready to present the list to the user list?
> > > >
> > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>
> > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > +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 <
> [hidden email]>
> > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > 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 <
> [hidden email]>:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>:
> > > > > > > > > > >
> > > > > > > > > > > > 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
>

[Ivan Pavlukhin]

Alex,

I already added a couple of items to wishlist [1].

Yes, I agree that the process should be iterative. But I am confused
on what stage we are in a current interation? I suppose that Denis is
going to present a list of removal candidates which we as developers
agreed on. And should not we have that list already available
somewhere as a document? Now I see an infromation scattered in this
thread and the wishlist [1]. And it is not easy to me to realize where
we are now.

[1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist

чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <[hidden email]>:

>
> 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, Павлухин Иван <[hidden email]>:
>
> > 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, Павлухин Иван <[hidden email]>:
> > >
> > > 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 <[hidden email]>:
> > > >
> > > > 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 <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > Are we ready to present the list to the user list?
> > > > >
> > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > > > >
> > > > > > 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 <[hidden email]>
> > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > > +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 <
> > [hidden email]>
> > > > > > 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 <
> > > > > > > > > [hidden email]>
> > > > > > > > > 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 <
> > [hidden email]>:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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,
Ivan Pavlukhin

[daradurvs]

I think all agreed items should be marked @Deprecated in the code
base, so we will be able to remove them transparently for the
end-users.

On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <[hidden email]> wrote:

>
> Alex,
>
> I already added a couple of items to wishlist [1].
>
> Yes, I agree that the process should be iterative. But I am confused
> on what stage we are in a current interation? I suppose that Denis is
> going to present a list of removal candidates which we as developers
> agreed on. And should not we have that list already available
> somewhere as a document? Now I see an infromation scattered in this
> thread and the wishlist [1]. And it is not easy to me to realize where
> we are now.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>
> чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <[hidden email]>:
> >
> > 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, Павлухин Иван <[hidden email]>:
> >
> > > 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, Павлухин Иван <[hidden email]>:
> > > >
> > > > 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 <[hidden email]>:
> > > > >
> > > > > 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 <
> > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > Are we ready to present the list to the user list?
> > > > > >
> > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > > > > >
> > > > > > > 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 <[hidden email]>
> > > > > > 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 <[hidden email]>:
> > > > > > > >
> > > > > > > > > +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 <
> > > [hidden email]>
> > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > [hidden email]>:
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 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,
> Ivan Pavlukhin

--
Best Regards, Vyacheslav D.

[dmagda]

Igniters,

I did the first run through the wishlist and selected integrations and APIs
for discontinuation. My suggestion would be to use IEP-36 (Modularization)
page for the final list that we'll send to the user list for feedback:

   - Integrations for discontinuation:
   https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
   - APIs for removal:
   https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval

Please check those lists and let us know if you have any arguments against
discontinuation/removal of X. Also, if you believe that something listed in
the wishlist should be added to the EIP then let's discuss that.
Personally, I see the whishlist as a page with ideas while the IEP a final
plan for action.


-
Denis


On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <[hidden email]>
wrote:

> I think all agreed items should be marked @Deprecated in the code
> base, so we will be able to remove them transparently for the
> end-users.
>
> On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <[hidden email]> wrote:
> >
> > Alex,
> >
> > I already added a couple of items to wishlist [1].
> >
> > Yes, I agree that the process should be iterative. But I am confused
> > on what stage we are in a current interation? I suppose that Denis is
> > going to present a list of removal candidates which we as developers
> > agreed on. And should not we have that list already available
> > somewhere as a document? Now I see an infromation scattered in this
> > thread and the wishlist [1]. And it is not easy to me to realize where
> > we are now.
> >
> > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >
> > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> [hidden email]>:
> > >
> > > 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, Павлухин Иван <[hidden email]>:
> > >
> > > > 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, Павлухин Иван <[hidden email]>:
> > > > >
> > > > > 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 <[hidden email]>:
> > > > > >
> > > > > > 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 <
> > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > Are we ready to present the list to the user list?
> > > > > > >
> > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > > > > > >
> > > > > > > > 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 <
> [hidden email]>
> > > > > > > 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 <
> [hidden email]>:
> > > > > > > > >
> > > > > > > > > > +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 <
> > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > [hidden email]>:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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,
> > Ivan Pavlukhin
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[Alexey Zinoviev]

I have a few ideas, maybe somebody will support me
1. Exclude Spatial Indexes from API for removal (I don't know internal
issues, but is I'd like this kind of index)
2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
because I've ready to try support them (or dive in this question) I think
no so many work to support them or move to the separate module like
BigDataTools Integrations
3. Annotations based configuration of SQL - we should be careful with that,
I suppose it's useful feature
4. Ignite Messaging should be combined together with Kafka/different MQ
integration into one module for messaging support

What do you think guys?

пн, 22 июл. 2019 г. в 22:51, Denis Magda <[hidden email]>:

> Igniters,
>
> I did the first run through the wishlist and selected integrations and APIs
> for discontinuation. My suggestion would be to use IEP-36 (Modularization)
> page for the final list that we'll send to the user list for feedback:
>
>    - Integrations for discontinuation:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
>    - APIs for removal:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
>
> Please check those lists and let us know if you have any arguments against
> discontinuation/removal of X. Also, if you believe that something listed in
> the wishlist should be added to the EIP then let's discuss that.
> Personally, I see the whishlist as a page with ideas while the IEP a final
> plan for action.
>
>
> -
> Denis
>
>
> On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <[hidden email]>
> wrote:
>
> > I think all agreed items should be marked @Deprecated in the code
> > base, so we will be able to remove them transparently for the
> > end-users.
> >
> > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <[hidden email]>
> wrote:
> > >
> > > Alex,
> > >
> > > I already added a couple of items to wishlist [1].
> > >
> > > Yes, I agree that the process should be iterative. But I am confused
> > > on what stage we are in a current interation? I suppose that Denis is
> > > going to present a list of removal candidates which we as developers
> > > agreed on. And should not we have that list already available
> > > somewhere as a document? Now I see an infromation scattered in this
> > > thread and the wishlist [1]. And it is not easy to me to realize where
> > > we are now.
> > >
> > > [1]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > >
> > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > [hidden email]>:
> > > >
> > > > 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, Павлухин Иван <[hidden email]>:
> > > >
> > > > > 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, Павлухин Иван <[hidden email]>:
> > > > > >
> > > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > 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 <
> > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > Are we ready to present the list to the user list?
> > > > > > > >
> > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
> > > > > > > >
> > > > > > > > > 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 <
> > [hidden email]>
> > > > > > > > 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 <
> > [hidden email]>:
> > > > > > > > > >
> > > > > > > > > > > +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 <
> > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > [hidden email]>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 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
> <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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,
> > > Ivan Pavlukhin
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[Denis Magda]

Alexey,

I've changed format on the wiki so that every community member can cast +1
and -1 vote explaining his/her stance. This should help us to filter out
those integrations that everyone agrees to discontinue vs. those that are
controversial. Please, *everyone interested* share your opinion by putting
a name and +1/-1 in these tables:

   - Integrations for discontinuation:
   https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
   - APIs for removal:
   https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval



1. Exclude Spatial Indexes from API for removal (I don't know internal
> issues, but is I'd like this kind of index)


Both spatial and full-text search indexes provide limit support and not
integrated with Ignite's memory architecture. It's better for us to remove
them in Ignite 3.0 (that will go with a new API to be proposed soon by Alex
Goncharuk) and rebuild from scratch in 3.1/3.2.


> 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> because I've ready to try support them (or dive in this question) I think
> no so many work to support them or move to the separate module like
> BigDataTools Integrations


Why don't we have them as separate Github projects that can be updated both
by the community members and independent developers? I just don't want this
to be a burden of the community to test and maintain it for every release.

3. Annotations based configuration of SQL - we should be careful with that,
> I suppose it's useful feature


Alex Goncharuk should propose a new API for 3.0 soon.

4. Ignite Messaging should be combined together with Kafka/different MQ
> integration into one module for messaging support


I wouldn't do this because 3rd party MQs go with their own versions that
start conflicting over the time. For instance, we already have several
modules for Hibernate and Spring Data integrations. To fix that, we just
need to store integrations in separate repos and do forks if a new
conflicting version has to be supported but there is still significant
usage of the old one.

--
Denis Magda


On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <[hidden email]>
wrote:

> I have a few ideas, maybe somebody will support me
> 1. Exclude Spatial Indexes from API for removal (I don't know internal
> issues, but is I'd like this kind of index)
> 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> because I've ready to try support them (or dive in this question) I think
> no so many work to support them or move to the separate module like
> BigDataTools Integrations
> 3. Annotations based configuration of SQL - we should be careful with that,
> I suppose it's useful feature
> 4. Ignite Messaging should be combined together with Kafka/different MQ
> integration into one module for messaging support
>
> What do you think guys?
>
> пн, 22 июл. 2019 г. в 22:51, Denis Magda <[hidden email]>:
>
> > Igniters,
> >
> > I did the first run through the wishlist and selected integrations and
> APIs
> > for discontinuation. My suggestion would be to use IEP-36
> (Modularization)
> > page for the final list that we'll send to the user list for feedback:
> >
> >    - Integrations for discontinuation:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> >    - APIs for removal:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> >
> > Please check those lists and let us know if you have any arguments
> against
> > discontinuation/removal of X. Also, if you believe that something listed
> in
> > the wishlist should be added to the EIP then let's discuss that.
> > Personally, I see the whishlist as a page with ideas while the IEP a
> final
> > plan for action.
> >
> >
> > -
> > Denis
> >
> >
> > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <[hidden email]
> >
> > wrote:
> >
> > > I think all agreed items should be marked @Deprecated in the code
> > > base, so we will be able to remove them transparently for the
> > > end-users.
> > >
> > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <[hidden email]>
> > wrote:
> > > >
> > > > Alex,
> > > >
> > > > I already added a couple of items to wishlist [1].
> > > >
> > > > Yes, I agree that the process should be iterative. But I am confused
> > > > on what stage we are in a current interation? I suppose that Denis is
> > > > going to present a list of removal candidates which we as developers
> > > > agreed on. And should not we have that list already available
> > > > somewhere as a document? Now I see an infromation scattered in this
> > > > thread and the wishlist [1]. And it is not easy to me to realize
> where
> > > > we are now.
> > > >
> > > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > >
> > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > > [hidden email]>:
> > > > >
> > > > > 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, Павлухин Иван <[hidden email]>:
> > > > >
> > > > > > 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, Павлухин Иван <[hidden email]
> >:
> > > > > > >
> > > > > > > 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 <[hidden email]>:
> > > > > > > >
> > > > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Denis,
> > > > > > > > >
> > > > > > > > > Are we ready to present the list to the user list?
> > > > > > > > >
> > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]
> >:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > [hidden email]>
> > > > > > > > > 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 <
> > > [hidden email]>:
> > > > > > > > > > >
> > > > > > > > > > > > +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 <
> > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > [hidden email]>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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
> > <
> > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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,
> > > > Ivan Pavlukhin
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>

[Alexey Zinoviev]

Thanks for the clarification, will try to vote

чт, 25 июл. 2019 г. в 04:11, Denis Magda <[hidden email]>:

> Alexey,
>
> I've changed format on the wiki so that every community member can cast +1
> and -1 vote explaining his/her stance. This should help us to filter out
> those integrations that everyone agrees to discontinue vs. those that are
> controversial. Please, *everyone interested* share your opinion by putting
> a name and +1/-1 in these tables:
>
>    - Integrations for discontinuation:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
>    - APIs for removal:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
>
>
>
> 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > issues, but is I'd like this kind of index)
>
>
> Both spatial and full-text search indexes provide limit support and not
> integrated with Ignite's memory architecture. It's better for us to remove
> them in Ignite 3.0 (that will go with a new API to be proposed soon by Alex
> Goncharuk) and rebuild from scratch in 3.1/3.2.
>
>
> > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > because I've ready to try support them (or dive in this question) I think
> > no so many work to support them or move to the separate module like
> > BigDataTools Integrations
>
>
> Why don't we have them as separate Github projects that can be updated both
> by the community members and independent developers? I just don't want this
> to be a burden of the community to test and maintain it for every release.
>
> 3. Annotations based configuration of SQL - we should be careful with that,
> > I suppose it's useful feature
>
>
> Alex Goncharuk should propose a new API for 3.0 soon.
>
> 4. Ignite Messaging should be combined together with Kafka/different MQ
> > integration into one module for messaging support
>
>
> I wouldn't do this because 3rd party MQs go with their own versions that
> start conflicting over the time. For instance, we already have several
> modules for Hibernate and Spring Data integrations. To fix that, we just
> need to store integrations in separate repos and do forks if a new
> conflicting version has to be supported but there is still significant
> usage of the old one.
>
> --
> Denis Magda
>
>
> On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <[hidden email]>
> wrote:
>
> > I have a few ideas, maybe somebody will support me
> > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > issues, but is I'd like this kind of index)
> > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > because I've ready to try support them (or dive in this question) I think
> > no so many work to support them or move to the separate module like
> > BigDataTools Integrations
> > 3. Annotations based configuration of SQL - we should be careful with
> that,
> > I suppose it's useful feature
> > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > integration into one module for messaging support
> >
> > What do you think guys?
> >
> > пн, 22 июл. 2019 г. в 22:51, Denis Magda <[hidden email]>:
> >
> > > Igniters,
> > >
> > > I did the first run through the wishlist and selected integrations and
> > APIs
> > > for discontinuation. My suggestion would be to use IEP-36
> > (Modularization)
> > > page for the final list that we'll send to the user list for feedback:
> > >
> > >    - Integrations for discontinuation:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > >    - APIs for removal:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> > >
> > > Please check those lists and let us know if you have any arguments
> > against
> > > discontinuation/removal of X. Also, if you believe that something
> listed
> > in
> > > the wishlist should be added to the EIP then let's discuss that.
> > > Personally, I see the whishlist as a page with ideas while the IEP a
> > final
> > > plan for action.
> > >
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <
> [hidden email]
> > >
> > > wrote:
> > >
> > > > I think all agreed items should be marked @Deprecated in the code
> > > > base, so we will be able to remove them transparently for the
> > > > end-users.
> > > >
> > > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <[hidden email]>
> > > wrote:
> > > > >
> > > > > Alex,
> > > > >
> > > > > I already added a couple of items to wishlist [1].
> > > > >
> > > > > Yes, I agree that the process should be iterative. But I am
> confused
> > > > > on what stage we are in a current interation? I suppose that Denis
> is
> > > > > going to present a list of removal candidates which we as
> developers
> > > > > agreed on. And should not we have that list already available
> > > > > somewhere as a document? Now I see an infromation scattered in this
> > > > > thread and the wishlist [1]. And it is not easy to me to realize
> > where
> > > > > we are now.
> > > > >
> > > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > >
> > > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > > > [hidden email]>:
> > > > > >
> > > > > > 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, Павлухин Иван <[hidden email]
> >:
> > > > > >
> > > > > > > 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, Павлухин Иван <
> [hidden email]
> > >:
> > > > > > > >
> > > > > > > > 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 <[hidden email]
> >:
> > > > > > > > >
> > > > > > > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Denis,
> > > > > > > > > >
> > > > > > > > > > Are we ready to present the list to the user list?
> > > > > > > > > >
> > > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <
> [hidden email]
> > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > [hidden email]>:
> > > > > > > > > > > >
> > > > > > > > > > > > > +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 <
> > > > > > > [hidden email]>
> > > > > > > > > > > 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
> <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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 <
> > > > > > > [hidden email]>:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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
> > > <
> > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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,
> > > > > Ivan Pavlukhin
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> >
>

[dmagda]

Folks, I've seen that someone added Spark to the list of "Integrations for
Discontinuation". I wouldn't do this. IMO, Spark is one of the key
integrations along with Spring Data, TensorFlow, Kafka that should be moved
out of the core but to be supported by the community:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IgniteModules
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IgniteModules>
-
Denis


On Thu, Jul 25, 2019 at 1:21 AM Alexey Zinoviev <[hidden email]>
wrote:

> Thanks for the clarification, will try to vote
>
> чт, 25 июл. 2019 г. в 04:11, Denis Magda <[hidden email]>:
>
> > Alexey,
> >
> > I've changed format on the wiki so that every community member can cast
> +1
> > and -1 vote explaining his/her stance. This should help us to filter out
> > those integrations that everyone agrees to discontinue vs. those that are
> > controversial. Please, *everyone interested* share your opinion by
> putting
> > a name and +1/-1 in these tables:
> >
> >    - Integrations for discontinuation:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> >    - APIs for removal:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> >
> >
> >
> > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> >
> >
> > Both spatial and full-text search indexes provide limit support and not
> > integrated with Ignite's memory architecture. It's better for us to
> remove
> > them in Ignite 3.0 (that will go with a new API to be proposed soon by
> Alex
> > Goncharuk) and rebuild from scratch in 3.1/3.2.
> >
> >
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> >
> >
> > Why don't we have them as separate Github projects that can be updated
> both
> > by the community members and independent developers? I just don't want
> this
> > to be a burden of the community to test and maintain it for every
> release.
> >
> > 3. Annotations based configuration of SQL - we should be careful with
> that,
> > > I suppose it's useful feature
> >
> >
> > Alex Goncharuk should propose a new API for 3.0 soon.
> >
> > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> >
> >
> > I wouldn't do this because 3rd party MQs go with their own versions that
> > start conflicting over the time. For instance, we already have several
> > modules for Hibernate and Spring Data integrations. To fix that, we just
> > need to store integrations in separate repos and do forks if a new
> > conflicting version has to be supported but there is still significant
> > usage of the old one.
> >
> > --
> > Denis Magda
> >
> >
> > On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <[hidden email]>
> > wrote:
> >
> > > I have a few ideas, maybe somebody will support me
> > > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> > > 3. Annotations based configuration of SQL - we should be careful with
> > that,
> > > I suppose it's useful feature
> > > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> > >
> > > What do you think guys?
> > >
> > > пн, 22 июл. 2019 г. в 22:51, Denis Magda <[hidden email]>:
> > >
> > > > Igniters,
> > > >
> > > > I did the first run through the wishlist and selected integrations
> and
> > > APIs
> > > > for discontinuation. My suggestion would be to use IEP-36
> > > (Modularization)
> > > > page for the final list that we'll send to the user list for
> feedback:
> > > >
> > > >    - Integrations for discontinuation:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > > >    - APIs for removal:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> > > >
> > > > Please check those lists and let us know if you have any arguments
> > > against
> > > > discontinuation/removal of X. Also, if you believe that something
> > listed
> > > in
> > > > the wishlist should be added to the EIP then let's discuss that.
> > > > Personally, I see the whishlist as a page with ideas while the IEP a
> > > final
> > > > plan for action.
> > > >
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <
> > [hidden email]
> > > >
> > > > wrote:
> > > >
> > > > > I think all agreed items should be marked @Deprecated in the code
> > > > > base, so we will be able to remove them transparently for the
> > > > > end-users.
> > > > >
> > > > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <[hidden email]
> >
> > > > wrote:
> > > > > >
> > > > > > Alex,
> > > > > >
> > > > > > I already added a couple of items to wishlist [1].
> > > > > >
> > > > > > Yes, I agree that the process should be iterative. But I am
> > confused
> > > > > > on what stage we are in a current interation? I suppose that
> Denis
> > is
> > > > > > going to present a list of removal candidates which we as
> > developers
> > > > > > agreed on. And should not we have that list already available
> > > > > > somewhere as a document? Now I see an infromation scattered in
> this
> > > > > > thread and the wishlist [1]. And it is not easy to me to realize
> > > where
> > > > > > we are now.
> > > > > >
> > > > > > [1]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > >
> > > > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > > > > [hidden email]>:
> > > > > > >
> > > > > > > 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, Павлухин Иван <
> [hidden email]
> > >:
> > > > > > >
> > > > > > > > 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, Павлухин Иван <
> > [hidden email]
> > > >:
> > > > > > > > >
> > > > > > > > > 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 <
> [hidden email]
> > >:
> > > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Denis,
> > > > > > > > > > >
> > > > > > > > > > > Are we ready to present the list to the user list?
> > > > > > > > > > >
> > > > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <
> > [hidden email]
> > > >:
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > [hidden email]>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > > > 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
> > <
> > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > [hidden email]>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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
> > > > <
> > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > [hidden email]>:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 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,
> > > > > > Ivan Pavlukhin
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> > >
> >
>