So the only breaking thing is that projects using the MessageObserver directly will not receive any notifications anymore?
Here I am not sure how Eclipse defines API breakage…
On the one hand, an upgrade from 1.0.x to 1.1.x could imply some adaptions to be made, when this is communicated properly.
The MessageObserver was intended as internal API!
On the other hand, some projects will not work anymore in observe situations when people just increase the version number
in their dependency. This is definitely annoying for the users.
Ciao
Matthias
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Julien Vermillard
Sent: Donnerstag, 7. April 2016 18:04
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: Re: [cf-dev] observation persistence
After looking at the code it's looking fine to me.
methods signature change are not a big API break, but the behaviour changes is quite important.
As soon it's merged in 1.1 or 2.0 branch we will need a milestone to use it for leshan.
I'm still not sure to known how much we can break API in the master (1.1) but I'm for merging there :)
On Wed, Apr 6, 2016 at 3:37 PM, Simon Bernard <contact@xxxxxxxxxxxxxxx> wrote:
I create a PR[1] about observation persistency.
I think this is in reviewable(mergeable?) state. So feedback are welcome.
The next question is: In which branch should we integrate this ? 1.1 or 2.0 ?
We can avoid API break (this is mainly API addition), but the behavior changed as now notifications are no more available on MessageObserver but on NotificationListener.
[1]https://github.com/eclipse/californium/pull/16
Le 11/02/2016 15:44, Simon Bernard a écrit :
Julien wrote a wiki page about that :
https://github.com/eclipse/leshan/wiki/Cluster .
Le 14/01/2016 17:56, Kai a écrit :
I am not very familiar with the specifics of the state Californium keeps in memory for maintaining observations. However, what you write makes sense to me.
The problem actually goes even deeper if you also consider the state kept by Scandium (DTLS sessions).
My understanding is that we are having this discussion in the context of making leshan (and thus Californium) highly available, i.e. being able to fail over between instances. Maybe we should start to work on that in the context of a set
of features adding support for HA on each level of the stack (scandium, californium, leshan) while trying to establish a mechanism that allows for maintaining consistent state across all layers.
I think it is important to address this problem consistently at all layers ...
Not so much success with this one :p.
@Matthias, @Kai, what do you think about that ?
Le 10/12/2015 15:45, Simon Bernard a écrit :
> Hi,
> In Leshan, we have an ObservationRegistry interface. We provide an
> in memory implementation. The idea should be to let users implements
> persistence if they need it.
> But for observe, we must be able to persist the californium state
> too. Should it exist a way to do that? (I look at the code, and I
> don't think so)
> I suppose if you want to do that we should mainly persist data in
> org.eclipse.californium.core.network.Matcher. (exchangesByMID,
> exchangesByToken)
> Does it make sense ?
> Simon
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|