[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Release Plan for Californium ?
|
RFC7959 (blockwise), section 2.4, page 13,
"Block-wise transfers can be used to GET resources whose
representations are entirely static (not changing over time at all,
such as in a schema describing a device), or for dynamically changing
resources. In the latter case, the Block2 Option SHOULD be used in
conjunction with the ETag Option ([RFC7252], Section 5.10.6), to
ensure that the blocks being reassembled are from the same version of
the representation: The server SHOULD include an ETag Option in each
response."
So the issue with dynamic content is more bound to the proper use of the ETag option.
As far as I understand californium, to provide a ETag is the responsibility of the " CoapResource" or
"Resource" implementation. And the CoAP client should check the ETag to detect a change in the
payload. Currently this seems to be missing in the blockwise transfer on the client side. But I hope,
this should be not a too big story.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Donnerstag, 17. November 2016 10:10
An: cf-dev@xxxxxxxxxxx
Betreff: Re: [cf-dev] Release Plan for Californium ?
On Wed, 2016-11-16 at 16:55 +0100, Simon Bernard wrote:
> It sounds good to me to put coap+tcp in a more long term branch.
>
ok, we seem to agree on that.
> About the blockwise, we currently use the 2.0.0M2 version of
> californium and it seems to works :).
I wish this were true. However, the more complex cases where a client receives another notification while a blockwise transfer (for the previous notification) is still ongoing, do not work because we (currently) create a new Exchange object for each notification received and therefore the ObserveLayer cannot determine whether it is already conducting a blockwise transfer for the token. It will therefore always start an additional series of blockwise GETs to retrieve all blocks. The "older" blockwise transfers will therefore end up intermixing "old"
blocks with "new" blocks and for each notification received the application layer will receive a Response containing the (potentially erroneously) assembled payload.
> This is just a feeling but I have some doubt about the possibility to
> extract the blockwise transfer from the stack without extracting the
> observe layer which is upper it.
> As a Leshan developper and so Californium user, I also appreciate the
> transparent way blockwise is currently handled. How will this change
> impact the API ?
>
I do understand that from a user's perspective it seems desirable to have Californium handle the blockwise transfers automagically "under the hood".
However, the way this currently is implemented is a maintenance nightmare.
Whenever I change one line of code in the matcher, I spend days trying to get the blockwise tests succeeding again. My hope is that we can reduce the CoapStack to its basic functionality of simply sending a request and receiving a response and let code outside of the CoapStack do the interpretation of observe flags and, in particular, handle blockwise transfers.
Coming back to your question: I think that this will completely change the API (at least when doing blockwise transfers) and that is also the reason why we need to do it as part of a major version change (like 2.0.x ;-))
> About fixing the scope or the date, I prefer to fix the scope. This
> allow us to know which modification go in the 2.0 banch and which go
> in the more long term branch (3.0 ?)
>
Fine with me. The challenge will be to agree on scope, I guess ...
> Le 16/11/2016 à 16:01, Hudalla Kai (INST/ESY1) a écrit :
> > On Wed, 2016-11-16 at 14:52 +0100, Simon Bernard wrote:
> > > Hi,
> > >
> > > At Leshan, we currently think about releasing a first Leshan version.
> > >
> > > You can see the plan on leshan-dev [1].
> > >
> > > This version of Leshan will be based on Californium 2.0.x as
> > > we need the persistent ObservationStore.
> > >
> > > There is a lot of activity on this branch which is a good
> > > point for californium project but I'm wondering if this is
> > > compatible with the needs to get a stable version of Californium 2.0.x ?
> > >
> > > WDYT ?
> > >
> >
> > I understand your concerns regarding "convergence" of the 2.0.x branch.
> > However,
> > the 2.0.x branch provides the opportunity to make some more radical
> > changes that involve breaking the API. This "window of opportunity"
> > will be closed once we do a 2.0.0 release and we will then need to
> > create a 3.0.x branch in order to work on other changes that will
> > potentially break the API (again). IMHO we therefore need to come to
> > an agreement what we think should be part of 2.0.x and what should
> > be postponed to the next release(s).
> >
> > The recent developments around the coap-over-tcp-draft have led me
> > to believe that we will not be able to have coap+tcp support (based
> > on the latest coap-
> > over-
> > tcp draft) in Californium any time soon. It also seems like we will
> > need to do some more (bigger) changes in Californium to support
> > observations and clustering over TCP correctly. Personally, I would
> > therefore like to postpone TCP to a later version.
> >
> > The biggest problem I currently have with the 2.0.x branch is the
> > quality of the transparent blockwise transfer behavior. My gut tells
> > me that we should remove the Blockwise layer as part of 2.0.0 in
> > order to simplify the core protocol stack and make it easier to
> > change things in the stack later on.
> >
> > I know that I have been talking about this for quite some time now
> > but haven't really started to work on it. However, I really would
> > like to get this into 2.0.0.
> >
> > Maybe we can set a dead-line for work on 2.0.x and at that point
> > simply release whatever we then have finished?
> >
> > > Simon
> > >
> > > [1] https://dev.eclipse.org/mhonarc/lists/leshan-dev/msg00631.html
> > >
> > > _______________________________________________
> > > 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
