[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] MQTT Objective-C Client
|
Hi Jeff,
I don't have a link right now - I'm on vacation this week. When I get
back I'll see what I can find. Of course, each lawyer's advice is
unique, so you'd have to consult your own for definitive guidance.
Ian Craggs
On 19/02/14 18:55, Jeff Mesnil wrote:
Hi Ian,
Thanks for the information.
Do you a link about the issue with Apple distribution agreements?
My objc lib is shipping with Xcode project settings and I'd like to
ensure that there is no issue with that.
My company, Red Hat, contributes to some Open Source Objc libraries
and they ship with these files out of the box (e.g.
https://github.com/aerogear/aerogear-push-ios-registration).
jeff
On Wed, Feb 19, 2014 at 5:48 PM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Jeff,
when the Paho MQTT C client was being written at IBM, we were planning to
write an Objective C layer for it. But we had the same problem as this
contribution is facing: the Apple distribution agreements. At the time, our
advice was that we could not proceed, as no way could be found to distribute
such code.
So, we tested the Paho C client on MacOS and iOS and wrote some build
instructions, but that is all we could do.
At this point, I think the limitations for any MQTT Objective-C layer, or
client are likely to be legal rather than technical.
Ian
On 14/02/14 18:59, Jeff Mesnil wrote:
Hi,
I'm interested by the Objective-C client[1] that andy committed recently.
I've browsed this mailing list archive before subscribing but I did
not find a lot of information on it.
At first glance, this looks to be a whole implementation of a MQTT
client. Is there any reason why it could not leverage the mqtt.c[2]
code instead?
Given the easy bridge between C and Objective-C, I was wondering if
you thought about wrapping the low-level C in a Objective-C library
wrapper? (I did not look in details to the mqtt.c code but I assume
it's in good shape).
Looking at it, it runs on a NSRunLoop and a delegate.
Is it planned to "modernize" the API and leverage GCD and Blocks instead?
I tend to prefer API using blocks instead of delegates especially for
event-driven code that is likely to be written to handle MQTT messages
(as an example, I also wrote a ObjC library for STOMP using GCD and
blocks[4])
One reason I could think of rewriting the whole client in Objective-C
would be persist the message for QoS 1 and 2 but I have not found such
code in the current objc client. Is it something planned?
To give some context, I am writing a book on messaging protocols for
mobile devices and Web browsers and I have several chapters on MQTT.
When I started writing the chapter about MQTT on iOS, I could not find
a good Objective-C client, so I wrote one[5] :) It's wrapping the
libmosquitto C library and is far from complete (I'm not a MQTT
expert) but it's working for simple applications[6].
The book is scheduled for this summer. Andy, do you know if there is a
roadmap for the objc client?
If there is a good Objective-C client in Paho, I would have no problem
to rewrite the iOS chapter with it as long as the lib fits in my book
schedule.
If I have a lot more remarks on the current objc code but I just
wanted some more context information on the direction of this library
in order to provide some feedback and code contribution.
cheers,
jeff
[1] http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.objc.git/
[2] http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.c.git/
[3] http://mobile-web-messaging.net
[4] https://github.com/mobile-web-messaging/StompKit/blob/master/README.md
[5] https://github.com/jmesnil/MQTTKit
[6] https://github.com/jmesnil/MQTTExample
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
