[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [iot-pmc] Paho CQs ... The next generation
|
Jens,
(and Kai and other members of the PMC). Thank you very much for your
work on these CQs, it is much appreciated. No need to apologize, I
realize the complexity of the task, and the fact that I submitted a
number at the same time. I was on vacation when this email was sent,
and I missed it amongst all the others, which is the reason for the late
reply.
I hope that at least some of these CQs will be useful to other projects
- that we have reduced at least some future work for the PMC and those
projects.
I fully agree about the questions of C runtimes and networking libraries
for different operating systems. That is, there are some things to be
clarified, but that needs to be done beyond the scope of just Paho. I
hope that the current CQs are sufficient to allow the next release (1.2).
On the subject of the Web Browsers CQ for JavaScript, it is true that
the requirements are for JavaScript and WebSockets. And yes, the
WebSocket API is required for Paho to work. I called it Web Browsers
because I know that the Paho client will not work in Node.js for
instance, and that it was intended to be used in Web Browsers. And I
know that the Web Browsers have WebSocket support integrated with
JavaScript. I'm not sure how you would get the WebSocket API outside of
a web browser environment.
A CQ for JavaScript should be exempt prereq, but what would the
WebSockets library be? I'm hoping also prereq, as it is supplied by the
Web Browser in the case of Paho. I'll open the CQs for discussion.
The only other CQ outstanding then is:
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10814 OpenSSL for the
C client.
If you want to use TLS/SSL communications then you have to use this
library. You can use the library without TLS of course. We don't
distribute OpenSSL, but we do distribute binaries that link to it. There
are previous OpenSSL CQs such as
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8766, but I wanted a
more open ended one to include future versions. All the existing CQs
are works-with requests.
Ian
On 03/16/2016 10:30 AM, Jens Reimann wrote:
I really do have to apologize to Ian for the time it takes! Sorry!
So, Kai already provided a nice list and the idea of doing a combined
vote. However it somehow got stuck in the middle. And want to re-try his
approach and wrap it up as I see the current state. Following this
e-mail I will send out a few e-mail which I would like to use for
voting, since I also do think that we have a few simple CQs and a few
not-so-simple ones. Getting rid if the simpler ones will shorten the list!
== We have two pretty simple ones:
* https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10821 - lua -> +1 already
* https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10698 - Test and
Build dependencies for Paho
"Lua" seemed like a piggyback and Julien already gave a +1 after the IP
requested. Done. Nothing to do.
The build and test dependencies seem fine for me as well. -> Should be a
vote for works with in a separate mail thread.
== C/C++ based
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10815 - Visual C++
Redistributable
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10697 - libstdc++
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10656 - glibc
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10817 - TI cc3200 SDK
and firmware
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10699 - ARM mbed tools
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10820 - FreeRTOS + TCP
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10695 - arduino
I would consider the following all C/C++ based. As Kai, Ian and Roger
stated before, I also do think that the actual dependency is the C
runtime, C++ runtime and may use libstdc++, glibc or the platform
specific SDKs as its implementation. That would make "C runtime" a
pre-requisite dependency, and glibc a works-with as well as the other
embedded device specific SDKs.
Unless ... You are using some Microsoft specific API from the Visual C++
redistributable API. As an example, opening a file with "fopen" would be
the ANSI C standard function. Using the "OpenFile" function would be a
Microsoft specific API. Now we could look at this from a more abstract
point: As long as Paho can open file either way, "ANSI C" could be the
pre-requisite and any other function could be "workswith".
So from the point that Paho is a networking component, I guess that
"ANSI C", "C++ standard library" and "BSD sockets" would be sufficient.
But all those assumptions are only true if Paho only provides the source
code! And never any binaries which contain parts of the linked SDKs.
To be formally correct, we would need to have generic CQs for "ANSI C",
... but on the other hand how could be have Java without those? There is
no formal CQ for Java either. And I think this has to be improved, but
this should not be part of this discussion.
So I would suggest to proceed with all of them as "workswith".
== Language based
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10904 - .Net Framework
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10818 - Golang
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10696 - Python Version:
2 and 3
Those are all based on different programming languages. As was the lua
one. Since there is no real alternative for Golang, these all seem like
"pre-requisite" and possibly exempt. But this latter decision is made by
EMO AFAIR.
And:
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10819 - go.net
Would then be a simple dependency like an other JAR.
== The special one
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10816 - Web browsers
My first though was that we were talking about web browser ... however
the request actually is for JavaScript and the WebSocket API. I would
suggest to close those and re-open this as a dependency on "JavaScript"
... which is the same scenario as with the other languages, and in fact
I know so many Eclipse projects which already depend on this but never
formally requested a dependency. And the same goes for the WebSocket
API. However this part of Paho won't work without it, as far as I
understood.
== Conclusion/Suggestion
One vote thread for -> Test and Build dependencies for Paho (possibly
works with)
One vote thread for -> C/C++ core runtimes (possibly works with)
One vote thread for -> Languages (possibly pre-requisite)
Normal CQ for go.net -> No vote
Split up web browser CQ to -> JavaScript + WebSocket API
Let me know what you think ... possibly with a simple +1 or -1 ... If
you have objections to my suggestions on workswith or pre-requisite we
can do this in the vote, since we are actually voting "pre-requisite" or
"works-with" instead of +1 or -1.
Jens
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
