[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Release Plan for Californium ?
|
I am currently working on a fix for #155 [1] and in that course I am thinking
about implementing (transparent) support for ETags in blockwise transfers as
well.
A Resource implementation may include an ETag in a response it has created and
this ETag will then be used by the BlockwiseLayer for the block2 transfer to the
client. If the response created by the Resource implementation does not contain
an ETag, the BlockwiseLayer will create one transparently and use it for the
block2 transfer.
On the client side, the ETag from the response will be used to retrieve the
remaining blocks in a block2 transfer, making sure that all response blocks
actually carry the same ETag.
My only concern with this would be whether all clients supporting blockwise also
support proper handling of ETags.
WDYT?
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
On Thu, 2016-11-17 at 09:54 +0000, Kraus Achim (INST/ESY1) wrote:
> 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
> _______________________________________________
> 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
