• @Gordon (in post# 10:)

    edit: Compression (if you use heatshrink) may cause you some issues - since it'll use char code 255 which isn't allowed in StorageFile... I'll just post some comments on

    OOOOPS... - so no binary data what so ever... Then I would suggest a slightly different management, since obviously 255 is used to detect unused space?

    I know that this is very space efficient, but I'd rather prefer - or have the option - 'wasting' some more bytes to have a way of knowing a (variable) record length. I could even think or having some time/performance optimizing information in the -kept alive RAM - that - if lost because of complete de-powering - can be recovered (with some kind of more expensive way like 'walking a chain' / following a block/record list where each of them knows its length and the last one in the list knows about to be the last one).

    Alternatives is to be able to have more than one storage and they can be of different type / behavior when it comes to manage size and space: require("Storage").n(<aNumber>).setup(<s­omeOptionObject\>) for setup and require("Storage").n(<aNumber>).... for use.

    Other alternative keeping single storage could define file extension(s) that indicate how the (allocated) space in/for the particular file is handled and, optional, leave it up to app specific/selectable space management function set/object to do the space management.

About

Avatar for allObjects @allObjects started