ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vyacheslav Daradur <daradu...@gmail.com>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Wed, 17 Jul 2019 12:51:08 GMT
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 Павлухин Иван <vololo100@gmail.com> 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, Павлухин Иван <vololo100@gmail.com>:
> >
> > Folks,
> >
> > Sorry if I am repeating something. I checked a page [1] and have not
> > found several items.
> > 1. I thought that there was an agreement of dropping OLD service grid,
> > was not it?
> > 2. Also IndexingSpi seems to me as a candidate for removal.
> >
> > Should I add those items to the page? Or is there another page
> > containing items to be removed that we agreed on?
> >
> > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >
> > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dmagda@apache.org>:
> > >
> > > Alex, Igniters, sorry for a delay. Got swamped with other duties.
> > >
> > > Does it wait till the next week? I'll make sure to dedicate some time for
> > > that. Or if we'd like to run faster then I'll appreciate if someone else
> > > steps in and prepares a list this week. I'll help to review and solidify it.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk <alexey.goncharuk@gmail.com>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Are we ready to present the list to the user list?
> > > >
> > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dmagda@apache.org>:
> > > >
> > > > > I wouldn't kick off dozens of voting discussions. Instead, the content
on
> > > > > the wiki page needs to be cleaned and rearranged. This will make
the
> > > > > content readable and comprehensible. I can do that.
> > > > >
> > > > > Next, let's ask the user community for an opinion. After reviewing
and
> > > > > incorporating the latter we can do one more dev list discussion with
the
> > > > > last call for opinions. Next, will be the voting time. If there is
a
> > > > > feature someone from the dev list is against of removing, then we
can
> > > > start
> > > > > a separate vote for it later. But let's get into those cases first.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov <dpavlov@apache.org>
> > > > wrote:
> > > > >
> > > > > > I propose each removal should have separated formal vote thread
with
> > > > > > consensus approval (since it is code modification).
> > > > > >
> > > > > > This means a single binding objection with justification is
a blocker
> > > > for
> > > > > > removal.
> > > > > >
> > > > > > We need separation to let community members pick up an interesting
> > > > topic
> > > > > > from email subject. Not all members reading carefully each post
in
> > > > > > mile-long threads.
> > > > > >
> > > > > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov <av@apache.org>:
> > > > > >
> > > > > > > +1 to email survey with following types of votes
> > > > > > > - silence (agree with all proposed removals)
> > > > > > > - we have to keep XXX because ...
> > > > > > >
> > > > > > > As a result, will gain lists
> > > > > > > "to be removed" - no one objected
> > > > > > > "can be removed" - single objection
> > > > > > > "should be kept" - multi objections
> > > > > > >
> > > > > > > Denis or Dmitry Pavlov, could you please lead this thread?
> > > > > > >
> > > > > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda <dmagda@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > Alex,
> > > > > > > >
> > > > > > > > I would do an email survey to hear an opinion of why
someone
> > > > > believes a
> > > > > > > > feature A has to stay. It makes sense to ask about
the APIs to be
> > > > > > removed
> > > > > > > > as well as integrations to go out of community support
[1] in the
> > > > > same
> > > > > > > > thread.
> > > > > > > >
> > > > > > > > Has everyone expressed an opinion? If yes, I can go
ahead and
> > > > format
> > > > > > the
> > > > > > > > wishlist page and make it structured for the user
thread.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
> > > > > > > > -
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <
> > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Anton, good point.
> > > > > > > > >
> > > > > > > > > Do you have any idea how we can keep track of
the voting? Should
> > > > we
> > > > > > > > launch
> > > > > > > > > a google survey or survey monkey? Voting by email?
> > > > > > > > >
> > > > > > > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov
<av@apache.org>:
> > > > > > > > >
> > > > > > > > > > Alexey,
> > > > > > > > > >
> > > > > > > > > > Thank's for keeping an eye on page updates.
> > > > > > > > > > Near Caches is not a bad feature, but it
should be used with
> > > > > > caution.
> > > > > > > > > > At least we have to explain how it works
on readme.io, why and
> > > > > > when
> > > > > > > it
> > > > > > > > > > should be used because usage can drop the
performance instead
> > > > of
> > > > > > > > > increasing
> > > > > > > > > > it.
> > > > > > > > > >
> > > > > > > > > > Anyway, I added near caches because I never
heard someone used
> > > > > them
> > > > > > > > > > meaningfully, not like a silver bullet.
> > > > > > > > > > So, that's just a proposal :)
> > > > > > > > > >
> > > > > > > > > > Also, I'd like to propose to have some voting
about full list
> > > > > later
> > > > > > > to
> > > > > > > > > gain
> > > > > > > > > > "must be removed", "can be removed" and
"should be kept" lists.
> > > > > > > > > >
> > > > > > > > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk
<
> > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Anton,
> > > > > > > > > > >
> > > > > > > > > > > I would like to pull-up the discussion
regarding the near
> > > > > caches
> > > > > > -
> > > > > > > I
> > > > > > > > > > cannot
> > > > > > > > > > > agree this is a feature that needs
to be removed. Near caches
> > > > > > > provide
> > > > > > > > > > > significant read performance improvements
and, to the best of
> > > > > my
> > > > > > > > > > knowledge,
> > > > > > > > > > > are used in several cases in production.
Can you elaborate on
> > > > > the
> > > > > > > > > > > shortcomings you faced? Maybe we can
improve both internal
> > > > code
> > > > > > and
> > > > > > > > > user
> > > > > > > > > > > experience?
> > > > > > > > > > >
> > > > > > > > > > > пт, 21 июн. 2019 г. в 10:42,
Dmitry Melnichuk <
> > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > >
> > > > > > > > > > > > Dmitry,
> > > > > > > > > > > > As a Python thin client developer,
I think that separate
> > > > > > > repository
> > > > > > > > > is
> > > > > > > > > > > > a truly great idea!
> > > > > > > > > > > > On Tue, 2019-06-18 at 21:29 +0300,
Dmitriy Pavlov wrote:
> > > > > > > > > > > > > - Move to separate repositories:
thin clients (at least
> > > > > > > non-Java
> > > > > > > > > > > > >
> > > > > > > > > > > > > > ones)
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best regards,
> Ivan Pavlukhin



-- 
Best Regards, Vyacheslav D.

Mime
View raw message