Thanks for raising the issue of making Wakaama better. I'd like to
highlight a few issues which (hopefully) contribute to the
discussion.
On merging Leshan and Wakaama:
- I'm neutral regarding having a common brand. However, from
empirical evidence, it appears Leshan is favoured for the (less
constrained) servers while wakaama works well for managed endpoints.
I'm sure I'm not alone in that regard but equally there probably are
lots of others who use one over the other exclusively. This has
inadvertently led to a side-effect of being tempted to cross-post
questions on both lists, particularly with regards to security and
interop between Leshan and wakaama.
The posting volume on the wakaama-dev is not that high, so if a
project merge does happen, I'd definitely endorse a single
developers' forum.
On making Wakaama better:
- It would be great if there was slightly better modularity to
shield LWM2M users (meaning those who implement and deploy
LWM2M/IPSO objects with Wakaama) away from the LWM2M development
(the Wakaama platform itself). Perhaps an API which is fairly stable
and well documented will help? Having 80 forks, while commendable,
does not necessarily indicate a growing community (the number of
pull requests is a better metric imho). Again, from personal
experience, I know developers and development teams (unfortunately
myself included) who fork because the code changes on the main
branch are so significant, and often frequent enough, to cause
user-level code to break. Tracing these in the code to understand
the changes and debugging consumes a significant amount of time, if
made to do that often enough.
Forking is effectively a stopgap measure to prevent this from
happening in some teams (i.e. the classic "We implemented some lwm2m
objects, let's freeze this to this specific wakaama branch and
timestamp to ensure future wakaama code changes won't break our
code"). On the other hand the high number of forks also goes to show
how important Wakaama is to the LWM2M community. That's why I feel
that having a fairly stable (and documented) API that documents the
different LWM2M interfaces (bootstrapping, registration, discovery,
object access, reporting..) would be significantly beneficial to
avoid such community fragmentation. Then, the platform itself can
use tags such -stable, -experimental, etc branches in the repo
(instead of using cmake and compile time flags).
I wrote this email (after thinking long and hard whether to reply or
not), as constructive criticism of the Wakaama project to give an
outsider's and user's perspective, and I hope the community would
construe it in the way it was written. Please accept my apologies if
I cause any offence inadvertently. That is certainly not my
intention. Thanks for all your continued efforts in creating and
developing something everyone can use, for free.
Regards,
Bill
On 20/11/16 21:39, Hatem Oueslati
wrote:
Guys,
this is my feeling too:
As
we could see it at the OMA Plugfest, it is actually a big
value to have 2 strong reference implementations of a
standard: diversity helps the standard to get better.
In
addition, C and Java code will anyway need to be kept
separated in different repos, I don’t see a clear value at
this point merging them into a single project.
As
for the branding name, today both projects are already
widely spread and adopted. Leshan has done a good job in
creating its own visual identity. I’m afraid that a name
change for Wakaama will create more confusion than value
(Joaquin can attest of a similar decision concerning the
Lightweight M2M branding).
Suggestions
on the feature list are pretty good.
Hatem
From marketing
point of view, merging both is maybe an interesting proposal
to solve our minor issue on website and logo.
But doing so, I'm afraid we will lose an important advantage
we have today having both separated with different project
leads and developer teams.
The fact, each one is implementing on its own the standard
with different team and they are working perfectly well
together, offers to those developments the status of
"reference implementations".
From my point of view, this coupled situation brings a big
value for both projects and the overall LWM2M offer at the end
by increasing robustness and reliability in regards of
standard compliancy.
Le 18/11/2016 à 21:25, Ian Skerrett a
écrit :
I
think merging Wakaama and Leshan into one project is an
interesting proposal. If we have other implementations,
like a JS implementation, would it also reside in Leshan?
I am just trying to understand the scope you are
suggesting.
From: wakaama-dev-bounces@xxxxxxxxxxx
[mailto:wakaama-dev-bounces@xxxxxxxxxxx]
On Behalf Of Julien Vermillard
Sent: Friday, November 18, 2016 11:14 AM
To: Wakaama developer discussions <wakaama-dev@xxxxxxxxxxx>
Subject: Re: [wakaama-dev] Propositions to make
Wakaama better
Hi
Hatem,Thanks for your email.
For
Sierra Wireless, what we have on our todo list for
Wakaama:
-
separate CoAP response: when the processing of the
command is long, the CoAP server ack with an empty
message and send the response with another message
exchange.
-
better testing of wakaama, and having a way to say
this version (or commit id) of wakaama works well with
this version of leshan
- more
block1 (we did it for client receiving large connect
from server but we could need it for client for
sending a registration with a large payload)
-
improvement for the registration engine to make it
more reliable and using elastic retries
-
expose low level CoAP primitive for mixinfg LWM2M and
CoAP resources
For the
marketing effort (web site, logo, etc..) I think you
can rip the leshan website and ask eclispe to help for
the logo.
I would also propose another crazy idea: to fusion
wakaama with leshan, by keeping everything with the
leshan name, we can use the leshan logo & website
for everything, we keep to seperate code repo
(leshan-java for current leshan and leshan-C/embedded
for current wakaama code). Of course that would also
merging the commiter and project lead list.
On
Thu, Nov 17, 2016 at 6:12 PM, Hatem Oueslati <hatem.oueslati@xxxxxxxxxxx>
wrote:
Dear Wakaama Community,
For
the people in this list who don’t know me, let
me first introduce myself briefly. I’m Hatem
Oueslati, co-founder of the Wakaama project.
Indeed, David Navarro, Jacques Bourhis, and I,
based on our passion and long experience for
embedded systems and communication
technologies accumulated at Palm, Access and
Intel, we decided from a pure personal
initiative to create a reference
implementation of the very relevant and
promising OMA LWM2M standard. At that time, we
were employees of Intel (which we thank for
letting us develop it on our spare time) and
we naturally got this project hosted by the
Eclipse Foundation so that to be spread and
used widely by its vibrant open-source
community. Thus was born Wakaama.
(BTW
we had great fun brainstorming about its name
with Ian and Benjamin J).
I’m
glad to see that the community grew a lot
since the project creation, we are now:
- Almost
a 100 members all over the planet
- At
least 17 active contributors
- And
80 forks!
There
has been a lot of progresses but we can make
Wakaama even better. I think we’re missing:
- A
Website and its content so that developers get
better access to relevant information to get
started with the project (something equivalent
to Leshan’s website).
- A
logo so that Wakaama finally gets its visual
identity (we have nothing today).
- A
Roadmap or at least a roadmap discussion so
that we, as a community, have a clear
understanding of where Wakaama intends to go
in accordance with the LWM2M standardization
status. We can share our vision and the status
of the standardization efforts as we also sit
at the OMA and are very active in the
standardization efforts.
Any
objection before we actually put an action
plan in place with the Eclipse Foundation so
that to articulate the above points?
Who
is interested and wants to participate to
this?
Thank
you.
Hatem
OUESLATI
CEO and Co-Founder
IoTerop
Interoperability,
Security and Device Management solutions for
IoT
www.ioterop.com
email : hatem.oueslati@xxxxxxxxxxx
mobile : +33.(0)6.04.65.05.87
  
_______________________________________________
wakaama-dev mailing list
wakaama-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wakaama-dev
_______________________________________________
wakaama-dev mailing list
wakaama-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wakaama-dev
_______________________________________________
wakaama-dev mailing list
wakaama-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wakaama-dev
|
