Comments (15)
Hi Peter,
#13 for requirement 1 is ready for review.
from coap-shepherd.
#16 is ready, and the next one would be a big one :)
from coap-shepherd.
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!
from coap-shepherd.
Hi Mophy,
About your requirements:
1, I want to keepshepherd.permitJoin
function. Maybe we can add an option to let shepherd always permit join. And we can useshepherd.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?
from coap-shepherd.
1, I think option (b) will be better.
4, Yeah, you are right.
from coap-shepherd.
1, I think option (b) will be better.
4, Yeah, you are right.
Ok, PRs are on the way :)
from coap-shepherd.
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?
from coap-shepherd.
Yeah, I think just export the CoapShepherd
class is better.
from coap-shepherd.
#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.
from coap-shepherd.
Ok, we postpone change entrance signature to a major version bump.
from coap-shepherd.
#15 will add an autoReadResources
config option, and the default value is set to true
to provide backward compatibility.
from coap-shepherd.
Finally, #18 is ready. Besides the new storage layer, we also made the tests run faster :)
from coap-shepherd.
@PeterEB , please bump the version so we can access the latest version via npm install
:)
from coap-shepherd.
@mophy , I published a new version v0.3.0
. 😉
from coap-shepherd.
Thank you!
from coap-shepherd.
Related Issues (7)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coap-shepherd.