Experimental features - thin client protocol as a first candidate

[Vladimir Ozerov]

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.

[dsetrakyan]

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

[dmagda]

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

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

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