Could you please clarify: - Does this proposal affect the user in any way? - Does it introduce or remove functionality? - Does it affect compatibility?
As I understand, all the answers are NO, and this is only a refactoring - correct? Let's make this clear in the IEP P.S. Separate IEP naming for Ignite 3 is ok, but we have not switched yet, and we should not have two proposals with the same ID. Please fix this. On Thu, Feb 8, 2024 at 7:17 PM Anton Vinogradov <a...@apache.org> wrote: > Mikhail, as we discussed earlier, Ignite-3 should use it's own counters > since it's a different project. > Better case for me is to use I3EP-XX naming. > > Nikolay, +1 to your proposal. > > On Thu, Feb 8, 2024 at 6:57 PM Mikhail Pochatkin <m.a.pochat...@gmail.com> > wrote: > > > Hello, Nikolay. > > > > Thanks for your IEP. I would say that IEP-115 already exists in Apache > > Ignite 3 section. Looks like current available counter is 119. > > > > > > чт, 8 февр. 2024 г., 18:27 Николай Ижиков <nizhi...@apache.org>: > > > > > Hello, Igniters. > > > > > > I want to discuss IEP-115 [1] Binary infrastructure modularization > > > Two main goal of IEP: > > > > > > - remove coupling between specific marshaller(BinaryMarshaller) and > > Ignite > > > core code. > > > - simplify Binary code improvements. > > > - clear SerDes abstraction in core code. > > > > > > As a result of this IEP we will have an ability to decouple Ignite thin > > > client from ignite-core module. > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-115+Binary+infrastructure+modularization > > >
