[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] observation persistence
|
Sounds like the matcher needs an interface to register and extract special tokens. I had a similar idea in Copper (but way easier and flatter in implementation).
This could also prepare Californium for so-called unsolicited notifications, that is, servers can start sending notifications without a corresponding GET. This of course needs a way for the application to announce expected tokens.
> -----Original Message-----
> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Simon Bernard
> Sent: Donnerstag, 14. Januar 2016 17:00
> To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
> Subject: Re: [cf-dev] observation persistence
>
> 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
