On 06/24/2015 06:23 AM, Ashwini Sharma wrote: > Hello Sachin, List, > > SRMRegisterPersistentStorageHandler(), takes in the open, read, write, > close, unlink... function > pointers from the Application. The SVRDatabase file is as of now a text > file storing JSON string.
Iotivity is moving towards CBOR and therefore there is a desire to get rid of JSON dependency completely from lower 'C' stack. We initially want to convert entire 'C' stack to CBOR and then investigate updating Secure Resource Manager(SRM) to CBOR. > Will it remain the same going forward or the application writer has the > liberty to store the data as > he wants, e.g. using SQL DB, etc...? Eventually, SRM would want to verify the authenticity (and also maintain confidentiality) of data available in SVR database. This can only be achieved if SRM is the 'only' (excluding some 'trusted' management tools, such as Provisioning Tool etc) entity responsible for reading/writing the SVR database. Having said that, we can always modify existing Persistent Storage Interface (PSI) architecture to be a plugin-based model where we can have JSON, CBOR or SQLLite plugins loaded in SRM and SRM can use them to perform read/write. Although, this will require some design and implementation efforts. (I looked at SQLLite few months ago when we started on Basecamp feature set and the library footprint was mentioned as > 350K and therefore I was not sure if it will be the right choice for us. https://www.sqlite.org/footprint.html) > > If it is left to the application then the appliaction has to be aware of > the JSON formatting > used and all the fields incase he wants to manuipulate before storing > and recreate while reading, > As the SRM expects the JSON string to be read/written to DB file. > Apart from 'management tools', what other applications you expect which would want to read/write to SVR database? > All the persistent handler functions are expecting/using FILE pointer to > work on. Instead I think the > SUCCESS/FAILURE returns will be better way forward as the FILE pointer > may not be in alignment to android space apps. Can you elaborate this a little bit more? > > If not then I guess SRM can handle the file I/O at its end only. > > Please share your thoughts. > > Thanks, > Ashwini
