Re: [cf-dev] Release Plan for Californium ?

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

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