Further enhancements

[mophy]

Hi, Peter,

We are planning to do some enhancements to coap-shepherd, and wondering if you still have time and interest to discuss/merge our subsequent PRs to this project. If you do, we will submit PRs of those modifications; if not, we will start a new project, base on your codes, and keep your copyright, of cause.

We are working on a IoT platform and it's applications, and coap-shepherd is our first choice candidate to do LwM2M protocol adaptation. But it need some changes to meet our requirements:

1, Always permit join, let the customer decide whether to accept a client. Need a way to disable the _permitJoinTimer. 2, Do not read all resources of a client when it's registering, let the customer decide. Need an option to disable the auto _readAllResource action. 3, Add a new option to use the new _disableFiltering of node-coap, which was introduced in @mcollina/node-coap#201 . 4, Save device registration info in MongoDB instead of nedb. Need an abstract storage layer (and serval adaptors) for device registration info. 5, Do not save device resources in nedb, post them to client using a RESTful client. Need a mechanism to let customer decide what to do with newly-coming device resources.

Best Regards, Mophy Xiong

[PeterEB]

Hi Mophy,

About your requirements: 1, I want to keep shepherd.permitJoin function. Maybe we can add an option to let shepherd always permit join. And we can use shepherd.acceptDevIncoming to let the customer decide whether to accept a client. 2, 3, Ok, sounds good. 4, If only save device registration info. Why you want to use MongoDB instead of nedb? 5, Ok, split the business is good.

Feel free to ask any questions or make suggestions!

[mophy]

Hi Mophy,

About your requirements: 1, I want to keep shepherd.permitJoin function. Maybe we can add an option to let shepherd always permit join. And we can use shepherd.acceptDevIncoming to let the customer decide whether to accept a client. 2, 3, Ok, sounds good. 4, If only save device registration info. Why you want to use MongoDB instead of nedb? 5, Ok, split the business is good.

Feel free to ask any questions or make suggestions!

Hi Peter,

1, Yes, shepherd.acceptDevIncoming can be used for customer to decide whether to accept a client, but only when shepherd._joinable is not false, and we have no way to set shepherd._joinable to be always true. a), Since calling shepherd.permitJoin(0) have the same behavior with not calling it at all (shepherd._joinable is initialized to be false), we can assign shepherd.permitJoin(0) to be 'always permit join', or, b), Add a shepherd.alwaysPermitJoin(true) method.

4, Possible reasons: a), Performance. What if you have more than 1,000,000 devices? MongoDB is well known, high performance, and scalable, and should be more stable than nedb. b), Management. Think of how a customer backup the database? cp node_modules/coap-shepherd/lib/database/coap.db <dest_path>. Is it safe to copy that file when the server is running? c), Possibilities. What if a customer want to use MySQL?

[PeterEB]

1, I think option (b) will be better.

4, Yeah, you are right.

[mophy]

1, I think option (b) will be better.

4, Yeah, you are right.

Ok, PRs are on the way :)

[mophy]

Hi Peter,

13 for requirement 1 is ready for review.

[mophy]

To implement requirement 2, we need an autoReadResources(or any better name?) config option. But now, all config options are located in config.js. I don't think this is a good idea, cause customers are supposed to change and version-control this file, but this file is under their node_modules directory which is ought be version-control-ignored.

A better way is: let the customer pass a config object as an argument to the CoapShepherd constructor, and use config.js as default value for missing options.

But this leads to an other problem: Customer can not control the creation of CoapShepherd, when they require('coap-shepherd), they get an already-created instance of CoapShepherd. Normal way to do this is just export the CoapShepherd class, and let the customer to do the instancing work. This will cause the entrance signature to be changed from var cserver = require('coap-shepherd'); to var CoapShepherd = require('coap-shepherd'); var cserver = new CoapShepherd(/* <nothing> or {connectionType: 'udp4'} */);

What do you think?

[PeterEB]

Yeah, I think just export the CoapShepherd class is better.

[mophy]

14 will add a config argument to CoapShepherd constructor. Currently we didn't change the entrance signature, since that will break the compatibility of existing customer codes. Yet, we can use this trick to use the new constructor argument:

var Shepherd = require('coap-shepherd').constructor, cserver = new Shepherd({ip: '0.0.0.0'}); We can postpone the breaking change to a major version bump. Of cause, it can be done now, if you wish :)

BTW, #14 didn't pass the travis-ci checking, but we did pass the npm test using both node v8.15.0 and v10.1.0 in our environment, please verify that.

[PeterEB]

Ok, we postpone change entrance signature to a major version bump.

[mophy]

15 will add an autoReadResources config option, and the default value is set to true to provide backward compatibility.

[mophy]

16 is ready, and the next one would be a big one :)

[mophy]

Finally, #18 is ready. Besides the new storage layer, we also made the tests run faster :)

[mophy]

@PeterEB , please bump the version so we can access the latest version via npm install :)

[PeterEB]

@mophy , I published a new version v0.3.0. :wink:

[mophy]

Thank you!