Example with callbacks

[GoogleCodeExporter]

It would be nice to provide an example with callback usage. Available examples 
are too simple to demonstrate nanopb's functionality.

Original issue reported on code.google.com by bdemir...@gmail.com on 19 Dec 2012 at 9:33

[GoogleCodeExporter]

The file listing example in the 'example' folder does use callbacks. It uses it 
for processing the 'repeated FileInfo file' field, and also for binding nanopb 
stream to TCP socket. This is the kind of usage I envisioned when designing the 
callback mechanism: it avoids allocating any large buffers.

Do you have an idea for a new example? I.e. what more would it do with the 
callbacks?

Original comment by Petteri.Aimonen on 19 Dec 2012 at 10:22

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Actually i'm trying to use nested messages with repeated fields. One level 
nesting is fine but i think encoding/decoding something like this requires some 
work:

message Row {
  repeated bytes cell = 1;
}

message DataTable {
  repeated Row row = 1;
}

Original comment by bdemir...@gmail.com on 19 Dec 2012 at 4:20

[GoogleCodeExporter]

Hmm, nesting should work just the same as a single level does.

When you get a callback for the row, you can setup the inner callback in the 
Row structure. Then when you call pb_encode_submessage, the inner callback will 
get called and you can encode the contents.

Original comment by Petteri.Aimonen on 19 Dec 2012 at 5:00

[GoogleCodeExporter]

Thanks four your kind and fast responses Petteri. I'm working on it now. I 
think only one possible addition would be removing max_size for name field in 
FileInfo message. There's an another max_size attribute is exists on path field 
in ListFilesRequest message. So, this way, example can demonstrate 2nd level 
nesting too.

P.S. Sorry for bothering you from issues section. If i have more questions i'll 
post on nanopb group.

Original comment by bdemir...@gmail.com on 19 Dec 2012 at 5:08

[GoogleCodeExporter]

I wish to keep the example simple :)

If everything has to be limitless the application code becomes quite complex. I 
would suggest that you consider carefully if there could be some upper bound to 
e.g. cell size. The data has to go somewhere anyway. When working on an 
embedded system, you usually want the system to be as deterministic as 
possible. It may therefore make sense to always allocate the maximum size. That 
way you will notice at the development time if there is not enough space to 
store the message.

But not all nanopb applications are so deeply embedded. It seems that some 
people are using it simply because of the few dependencies. When working on a 
system with many megabytes of memory, dynamic allocation makes more sense.

To support that case properly, there should be an easy way to define that the 
'cell' field is to be dynamically allocated. The dynamic alloc branch already 
does this, but I haven't had time to merge the ideas back to master.

Anyway I agree that it would be better to discuss this on the google groups 
forum. I'll close this issue for now.

Original comment by Petteri.Aimonen on 19 Dec 2012 at 6:04

• Changed state: WontFix