Response to LC-2706

Hi Rumen,

Thank you very much for your feedback. Please find our comments inline.

> Subject: Evaluations of EXI in application areas with memory
> restrictions
> Section: 1. Introduction
> Paragraph: "Certain evaluations of EXI in the context of such areas..."
> Comments:
> It is good to have access to these evaluations.

We found that EXI is difficult to deploy on restricted devices (e.g., microcontrollers). Therefore we were focusing on constraints that on the one hand keep compatibility with EXI 1.0 and on the other hand support easy deployment on restricted devices. To better reflect this fact we updated the draft using the word "findings" instead of "evaluations".

>  From my own perspective and use cases this profile will not bring
> much benefits. I am working with very small messages over
> low-bandwidth wireless links (up to 250 kb/s). Of course, memory
> is an issue but the compression is even more important.

I would like to note that the EXI profile is very beneficial for device classes that cannot afford memory allocation at runtime and also need to deal with built-in element grammars. The profile makes it possible to account for the required memory at compile time which was not possible in EXI 1.0 before.
Further, the possibility of using global value string tables only (setting localValuePartitions to FALSE) reduces the code footprint on restricted devices and still provides a very good solution for documents containing lots of strings.

> It would be good to have some statistics on what are the trade-offs
> (memory usage vs compression) by using the Profile in different
> use-cases (size and structure of the messages).

The EXI profile may not have any effect on some EXI streams while at the same time reducing code footprint and memory usage. Unfortunately we are not yet able to provide any statistics or make any statement about memory usage vs. compression. These statistics highly depend on the used options and even more on the used test set (e.g., ratio between data encoded with schema-informed grammars vs. data encoded with built-in element grammars).

We hope that makes you understand our reasoning,

-- Daniel

Received on Thursday, 15 November 2012 08:05:54 UTC