Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] MQTT Embedded C Client Changes
I'd say fIf you don't make changes like renaming early (and at 1.0 is early), it'll only get way more painful later. And from personal experience, the inconsistency will naw at you :)



On Fri, 6 Nov 2015 at 07:30 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hello all,

I've painted myself into a bit of a corner with the embedded client C
implementation, and I'm wondering what to do.

Al Stockdill-Mander created it as a C clone of the C++ MQTTClient
embedded API, which I wrote initially for mbed.  On mbed, C++ is the
default language, so I used that.   For the platforms Al was working
with, C was the norm, C++ didn't work too well, so Al made the C clone.
I did suggest the possibility of converting the C++ code into C with a
script, but he didn't go for that :-)

It was part of the 1.0.0 release of the embedded client that I made in
February of this year, but I hadn't really looked at it too closely.
Recently I went to update it for FreeRTOS, and started on a general
cleanup, adding documentation, samples. (See the updates in the develop
branch:
http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.embedded-c.git/tree/MQTTClient-C/src?h=develop)

As a result I realized that I would really like to rename a few
functions, to make the pattern and meaning consistent - something like
ObjectOperation:

NewTimer -> TimerInit
InitTimer -> TimerInit
expired -> TimerIsExpired
countdown_ms -> TimerCountdownMS
countdown -> TimerCountdown
left_msg -> TimerLeftMS

NewNetwork -> NetworkInit
ConnectNetwork -> NetworkConnect

MQTTClient -> MQTTClientInit

All but the last of these changes are in the platform specific "helper"
files which provide the network and timer functions.  I think of these
as not being part of the core code, but I realize that view is probably
not shared by everyone.

Strictly, according to Eclipse convention, I should change the major
version number for breaking API changes.  I feel that's overkill in this
case. Some options:

- go ahead and create a 1.1 version, noting the name changes -- the
1.0.0 version would still be available in the repository
- I could  relegate the current code to a sub-folder, to make it easy
for people to make the transition
- I could leave the names unchanged, but I would prefer not to

Any thoughts welcome.

Thanks

--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

Back to the top