Incoming data prosessing about arduino-nats HOT 6 CLOSED

Great idea, you think the NATS::msg struct should expose an implementation of the Arduino Stream? I would make NATS::msg into a class with stream() and data() methods that return Stream and const char* respectively.

from arduino-nats.

Yes, that's is exactly how it should be, but how about if the msg class would directly implement the Stream interface. I don't see any reason to add a separate function to return it. As the data in the message ends before the whole stream we want to stay in control what is returned from the available() function. Because of this we don't want to return the client directly but instead wrap it and why not the the msg class.

from arduino-nats.

Another option could be that we would make the whole nats class implement the stream and instead of passing the message struct or class to the cb we could pass "this".

from arduino-nats.

I'll get started on having NATS::msg extend Stream, then. I wonder if I should even expose a function for reading the whole message since there's readBytes and readString, but it would be nice to have an automagically allocated data buffer without using Arduino's String class (ugh).

from arduino-nats.

Yes, let's stay away from the String. But for the same reason I would also like use static buffers. It would be a lot more efficient than allocating and deallocating back and forth all the time. As all the platforms that this lib is used with are single threaded there is no problem. Also I think it is unnecessary to implement in the formatted publishing in the lib. IMO this should be left to the user of the lib. Do One Thing and Do It Well and so on...

BTW the stream also implements the Print interface so the message becomes an object that you can for example directly write/read to/from an SD card and proxy it to other Streams. But is a bit tricky for example when you publish stuff. It could be done so that under the hood the publish would first call something like "beginPublish" with parameters subject, reply-to and number of bytes and then a separate function for sending the data. This way if the user of the lib wants to publish or reply with a stream it can be done with calling the beginPublish outside the lib to prepare the message and the just print the streamable data. At the same time it would work just like before if you just directly call publish.

The annoying part is that you need to know the length of the stream beforehand because the nats protocol requires it before the actual data. For example with SD card it's not a problem because you can read that info before the data.

from arduino-nats.

Also the aJson lib supports parsing/printing Streams. Parsing a message to aJson object will become as simple as:

aJsonStream aJsonStream(msg);
aJsonObject *parsedMessage = aJson.parse(&aJsonStream);

and the same works for sending:

aJsonStream aJsonStream(msg);
aJson.print(aJSONObject, &aJsonStream);

from arduino-nats.