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
