You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2017/09/13 12:21:10 UTC
Experimental features - thin client protocol as a first candidate
Igniters,
I would propose to add a concept of "experimental feature". Quite often we
face a situation when newly created feature has not-so-good API, or tested
insufficiently, etc.. Many vendors employ a concept of so-called
"experimental" features to mitigate the risks. Examples I am aware of:
Hadoop, Kotlin.
When feature is marked as experimental, there is no guarantees for API and
binary compatibility, neither it implies that the feature is bug-free. On
the other hand, users might start using the feature right away and provide
valuable feedback.
Let's add such concept to our product, and it would make it much better!
First candidate for this marker is our newly developed thin client. We put
a lot efforts to make it extensible in future, but I doubt it is possible
to take in count everything at once. Instead, I would rather release it as
"experimantel" in the scope of 2.3, and then finalize it as a part of 2.4
based on user's feedback.
What do you think?
Vladimir.
Re: Experimental features - thin client protocol as a first candidate
Posted by Николай Ижиков <ni...@gmail.com>.
Hello,
I think it is a very useful concept to have.
Other Apache projects have this conception too.
As an example I can provide spark special annotation for a public API [1]
InterfaceStability {
Unstable, Evolving, Stable
}
[1]
https://github.com/apache/spark/blob/master/common/tags/src/main/java/org/apache/spark/annotation/InterfaceStability.java
2017-09-13 22:35 GMT+03:00 Denis Magda <dm...@apache.org>:
> In first version the protocol version can be “0.1”, 0.2”, etc. Once we are
> sure the protocol is mature enough it can be stamped with version 1.0.
>
> The point is that the versions like 0.x imply that the protocol is not
> 100% final which is pretty similar but not that loud as the experimental
> label.
>
> —
> Denis
>
> > On Sep 13, 2017, at 12:12 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
> >
> > Vladimir,
> >
> > As far as the client, I don't think we need to call it experimental. An
> > "experimental" feature sounds like it might explode if you come close :)
> >
> > How about we have client protocol versions instead? Then each Ignite
> > release can announce which protocol versions it is compatible with.
> >
> > D.
> >
> > On Wed, Sep 13, 2017 at 5:21 AM, Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> >
> >> Igniters,
> >>
> >> I would propose to add a concept of "experimental feature". Quite often
> we
> >> face a situation when newly created feature has not-so-good API, or
> tested
> >> insufficiently, etc.. Many vendors employ a concept of so-called
> >> "experimental" features to mitigate the risks. Examples I am aware of:
> >> Hadoop, Kotlin.
> >>
> >> When feature is marked as experimental, there is no guarantees for API
> and
> >> binary compatibility, neither it implies that the feature is bug-free.
> On
> >> the other hand, users might start using the feature right away and
> provide
> >> valuable feedback.
> >>
> >> Let's add such concept to our product, and it would make it much better!
> >>
> >> First candidate for this marker is our newly developed thin client. We
> put
> >> a lot efforts to make it extensible in future, but I doubt it is
> possible
> >> to take in count everything at once. Instead, I would rather release it
> as
> >> "experimantel" in the scope of 2.3, and then finalize it as a part of
> 2.4
> >> based on user's feedback.
> >>
> >> What do you think?
> >>
> >> Vladimir.
> >>
>
>
--
Nikolay Izhikov
NIzhikov.dev@gmail.com
Re: Experimental features - thin client protocol as a first candidate
Posted by Denis Magda <dm...@apache.org>.
In first version the protocol version can be “0.1”, 0.2”, etc. Once we are sure the protocol is mature enough it can be stamped with version 1.0.
The point is that the versions like 0.x imply that the protocol is not 100% final which is pretty similar but not that loud as the experimental label.
—
Denis
> On Sep 13, 2017, at 12:12 PM, Dmitriy Setrakyan <ds...@apache.org> wrote:
>
> Vladimir,
>
> As far as the client, I don't think we need to call it experimental. An
> "experimental" feature sounds like it might explode if you come close :)
>
> How about we have client protocol versions instead? Then each Ignite
> release can announce which protocol versions it is compatible with.
>
> D.
>
> On Wed, Sep 13, 2017 at 5:21 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
>> Igniters,
>>
>> I would propose to add a concept of "experimental feature". Quite often we
>> face a situation when newly created feature has not-so-good API, or tested
>> insufficiently, etc.. Many vendors employ a concept of so-called
>> "experimental" features to mitigate the risks. Examples I am aware of:
>> Hadoop, Kotlin.
>>
>> When feature is marked as experimental, there is no guarantees for API and
>> binary compatibility, neither it implies that the feature is bug-free. On
>> the other hand, users might start using the feature right away and provide
>> valuable feedback.
>>
>> Let's add such concept to our product, and it would make it much better!
>>
>> First candidate for this marker is our newly developed thin client. We put
>> a lot efforts to make it extensible in future, but I doubt it is possible
>> to take in count everything at once. Instead, I would rather release it as
>> "experimantel" in the scope of 2.3, and then finalize it as a part of 2.4
>> based on user's feedback.
>>
>> What do you think?
>>
>> Vladimir.
>>
Re: Experimental features - thin client protocol as a first candidate
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Vladimir,
As far as the client, I don't think we need to call it experimental. An
"experimental" feature sounds like it might explode if you come close :)
How about we have client protocol versions instead? Then each Ignite
release can announce which protocol versions it is compatible with.
D.
On Wed, Sep 13, 2017 at 5:21 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> Igniters,
>
> I would propose to add a concept of "experimental feature". Quite often we
> face a situation when newly created feature has not-so-good API, or tested
> insufficiently, etc.. Many vendors employ a concept of so-called
> "experimental" features to mitigate the risks. Examples I am aware of:
> Hadoop, Kotlin.
>
> When feature is marked as experimental, there is no guarantees for API and
> binary compatibility, neither it implies that the feature is bug-free. On
> the other hand, users might start using the feature right away and provide
> valuable feedback.
>
> Let's add such concept to our product, and it would make it much better!
>
> First candidate for this marker is our newly developed thin client. We put
> a lot efforts to make it extensible in future, but I doubt it is possible
> to take in count everything at once. Instead, I would rather release it as
> "experimantel" in the scope of 2.3, and then finalize it as a part of 2.4
> based on user's feedback.
>
> What do you think?
>
> Vladimir.
>