[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Release Plan for Californium ?
|
On Tue, 2016-12-06 at 09:30 +0000, Kraus Achim (INST/ESY1) wrote:
> > To me this indicates that a client that claims to support blockwise transfers
> > as defined by RFC 7959 also MUST understand and consider ETags on block2
> > responses.
> > AFAIC this would allow us to _always_ include an ETag in a response that
> > requires a blockwise transfer, wouldn't it?
>
> According RFC 7252, 5.10, Table 4, ETag is not critical.
> So it's safe to include it, even if the receiver isn't able to process it.
>
Of course, my point is that we can also expect a client to actually understand
and process it, if it claims to support blockwise transfers.
A client that does not support blockwise transfers may or may not be able to use
the (first) block contained in the response. But that is the client's problem,
right?
>
> 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: Dienstag, 6. Dezember 2016 10:22
> An: cf-dev@xxxxxxxxxxx
> Betreff: Re: [cf-dev] Release Plan for Californium ?
>
> On Tue, 2016-12-06 at 08:58 +0000, Kraus Achim (INST/ESY1) wrote:
> > I think, the most clients will not support "dynamic blockwise" resources.
>
> And those, which support changing blockwise resource, either implement ETag or
> they have to define, how they want to handle that (best by starting a RFC core
> discussion :-) ).
>
> As you already pointed out, RFC 7959, Section 2.4 states that a server SHOULD
> include an ETag option for dynamically changing resources. It also states that
> "If an ETag Option is available, the client, when reassembling the
> representation from the blocks being exchanged, MUST compare ETag Options."
>
> To me this indicates that a client that claims to support blockwise transfers
> as defined by RFC 7959 also MUST understand and consider ETags on block2
> responses.
>
> AFAIC this would allow us to _always_ inlude an ETag in a response that
> requires a blockwise transfer, wouldn't it?
>
> > 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: Dienstag, 6. Dezember 2016 09:53
> An: cf-dev@xxxxxxxxxxx
> Betreff: 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.dewww.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
>
> _______________________________________________
> 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
