Maxim,
Mid next year is fine, but it makes more sense to bound it by time rather
than a specific version. For example, what if we want to release 2.14
earlier for whatever reason?
As for the guide, I obviously can't force anyone, but I still believe it is
useful, and I hope someone will pick
Hello Maxim,
The plan should be more precise. So at the very high level:
>
> 1. Deprecate the system cache in 2.13.
> 2. Remove the system cache in 2.14.
>
I still think that we should not be stuck to a concrete version 2.14.
The system cache should be removed when all related improvements will
Val,
The plan should be more precise. So at the very high level:
1. Deprecate the system cache in 2.13.
2. Remove the system cache in 2.14.
2.14 should happen in the mid of the next year I suppose.
I don't think we should write guides for the system cache >
metastorage migration process. This
Valentin,
> However, changes like system cache removal are much more critical, because a
> plugin might rely on it.
I’m still don’t understand - what is the difference between system cache and
any other Ignite cache except the name?
Do we have some special guarantees for system cache?
> Any
That's correct.
Folks, can we agree on how we want to approach the removal of the system
cache? Any objections to the plan I've suggested earlier? As a reminder,
here it is:
1. Write down the differences between the system cache and the metastorage,
and provide a transition guide for plugin
Hi,
> Plugins have access to different internal Ignite components, such as
security processor and others, and can extend the programmatic API of
Ignite.
> Where docs say that we, as a community, take responsibility to keep
internals in the way plugin expect?
Nikolay, it seems to me, that quoted
Slava, I don’t get it.
> Plugins have access to different internal Ignite components, such as security
> processor and others, and can extend the programmatic API of Ignite.
Where docs say that we, as a community, take responsibility to keep internals
in the way plugin expect?
> 6 дек. 2021
Hello Nikolay,
>> plugin framework allows to implement internal components and use the
internal API.
> Can you please, point out to documentation or place in Ignite code that
describe this behaviour?
Looks like it states here https://ignite.apache.org/docs/latest/plugins
> The Ignite plugin
Valentin
> plugin framework allows to implement internal components and use the
> internal API.
Can you please, point out to documentation or place in Ignite code that
describe this behaviour?
AFAIK plugin can only use public API, internal API can be changed any time we
want.
> Folks, can
Nikolay, that's right, plugin framework allows to implement internal
components and use the internal API. There is a difference between a plugin
and an extension that uses only public API
Folks, can anyone explain the rush? Is there any specific reason for it?
I think we all agree that this is a
I don’t understand how it possible.
Are you talking about plugin that uses some kind of internal API?
> 3 дек. 2021 г., в 18:50, Вячеслав Коптилин
> написал(а):
>
> Hello Nikolay,
>
> If I am not mistaken, the method you mentioned, allows to create a "user"
> cache that is available through
Hello Nikolay,
If I am not mistaken, the method you mentioned, allows to create a "user"
cache that is available through public api for the user. This does not
cover the case when the plugin developer wants to hide such cache and
protect it form the end user (at least, via public api).
Thanks,
> What is the issue if third-party plugins will create «ignite-sys-cache»
from the code?
Great idea!
On Fri, Dec 3, 2021 at 2:15 PM Nikolay Izhikov wrote:
> Vyacheslav, Val, can you please clarify - What is the issue if third-party
> plugins will create «ignite-sys-cache» from the code?
>
>
Vyacheslav, Val, can you please clarify - What is the issue if third-party
plugins will create «ignite-sys-cache» from the code?
Like just replacing `Ignite#cache` with the `Ignite#getOrCreateCache`.
> 2 дек. 2021 г., в 16:13, Вячеслав Коптилин
> написал(а):
>
> Hello Maxim,
>
>> I don't
Hello Maxim,
> I don't understand why you are using *backwards compatibility* for
completely internal things.
> Why you are thinking in terms of users usage when are talking about
ignite-sys-cache but not thinking when refactoring
First of all, we are talking about all plugin developers. It does
Pavel,
I don't understand why you are using *backwards compatibility* for
completely internal things. Why you are thinking in terms of users
usage when are talking about ignite-sys-cache but not thinking when
refactoring, for instance, all the checkpoint classes? Take a look at
the [1] issue.
Maxim,
> I don't think that we should wait for 3-rd party plugins to be updated
> this is an awful practice when the open-source product releases depend
> on some of the proprietary plugins
This makes no sense, sorry.
It is not that we depend on 3rd party plugins.
It is that *our users depend
Slava,
Thank you for the comments.
> Maxim, the community must provide a reasonable time interval in order to
> notify all contributors and wait for updating all 3-rd party plugins.
This is not actually true. We must notify about changes as earlier as
possible and not only users but all the
Agree with Slava. Two months is not enough time, especially considering
that the system cache is not functionally equivalent to the metastorage. I
suggest we do the following:
1. Write down the differences between the system cache and the metastorage,
and provide a transition guide for plugin
Hi Maxim,
> On the other hand, I don't see any valuable reason why the change can't
be done and we should wait for the future that never comes.
Maxim, the community must provide a reasonable time interval in order to
notify all contributors and wait for updating all 3-rd party plugins.
Honestly,
Hello Val,
Thank you for sharing the details. On the one hand, I agree with you
that there is no need to haste with this change and it must be
prepared carefully. On the other hand, I don't see any valuable reason
why the change can't be done and we should wait for the future that
never comes.
Maxim,
You're right that the system cache is still likely to be used by plugins.
We at GridGain use it for security features, for example. As far as I know,
that's not the only case.
I also agree that the metastorage should be the preferred way for this kind
of purposes, but is there any harm in
22 matches
Mail list logo
