Hope people don't mind me breaking this out to a seperate thread.
I've been working in this area and one point that was made previously was about using JSON data.
One thing I'd like to see taken forward would be JSON encoding/decoding built into the Network transport. I know this is non-traditional, but it would help application level programmers a lot.
Here's an example (C++), possibly with some pseudo-code:
if (client.in.havepacket())
{
t = client.in.packet.JSONasInt("Temp");
printf("Temp : %d\n", t);
}
There's a few blank bits of code that aren't to be included.
My point, is that for IoT, what the average user is going to be looking for is ease-of-use. And 1970's C, well, I've said before it's not as user friendly as more modern frameworks.
Assembling and disassembling packets isn't really something that users should be doing in these modern times. It's just too hard.
Hope people don't mind me breaking this out to a seperate thread.
Good idea.
I've been working in this area and one point that was made previously
was about using JSON data.
Just a few idea's..
I want something like that too.
But as underlying transport RIOT needs a minimized-to-the-minimum, flexible, realtime-capable IPC mechanism that allows us to implement something like the JSON idea some levels higher up.
Do you have any suggestions for a different name than "blip"?
I was also toying with "-gram" in my head but couldn't come up with
anything short and meaningful.
"grm" has a nice ring to it but no real meaning to the uninitiated.
All in all I still like "msg" best.
Me too... That's why I renamed the old API in the first place.
IMHO the main IPC functionality should be msg_*. But now we have legacy code, and also some semantically more defined "messages" might be useful. So there's a second, higher level messaging type. I called it pulse at first, blip now.
At first, I tried integrating the sized buffer into our existing messages. That looked awful in code.
copy over type, copy over value, check for size, maybe copy over buffer, ...
Without type and content, every message transfer is essentially a memcpy. And with that, you can easily implement everything else.
But the more that I use the AVR-Attiny85 in my projects, the more I think that varying levels of JSON support may be achievable. For example, limit JSON capabilities to the essentials on smaller processors (ie no sets, arrays or dictionaries).
What is interesting about JSON, is that it can be transmitted/passed/handled in single packets.
So my previous example code, really only adds field-assembly/dissassembly as something over the top of basic packet sending architecture.
Also, I'd just like to add the following. That there's many network interfaces that use uarts (David warns of "Return to the UART" and here is just one example based on new wifi-modules: https://www.zybuluo.com/kfihihc/note/31135
Me too... That's why I renamed the old API in the first place.
IMHO the main IPC functionality should be msg_*. But now we have
legacy code, and also some semantically more defined "messages" might
be useful.
msg_* isn't confusing for me as an IPC component.
Just to clarify. I want the new API to be msg_send, msg_receive, msg_node (for the endpoints). This is supposed to be *the* IPC API.
Problem is, it's not feasable to add the new flexibility while retaining the old API while keeping the core IPC as it should be: minimal and with maximum performance.
BUT we have a lot of legacy code. So I implemented the old API using the new, simpler functions (they're basically just wrappers). But in order to reserve the msg_* names for the new core API to rule them all, the old functions need to get out of the namespace.
Initially I proposed msg_pulse_*. Noone liked pulse. Now I'm trying "blip" and ask for suggestions.
> >What about IPC_* ? giving ipc_send, ipc_receive and so forth.
> Hm. Actually that's my favorite so far, but we'll still have both:
> msg_* and ipc_*.
>
> Not having heard of blip_ will maybe make you avoid it in the first
place,
> which is why I'm not using a fancy new name for the new API.
and here is just one example based on new wifi-modules: 
