>> It does seem like read_file() is only triggered if you have >> previously >> saved an actual file to filesystem, if you just have metadata, no >> call >> is ever made to read_file() so it's a rather bad place to pick-up the >> metadata. At least this is what I'm seeing here – I've just created a >> 0 size file in my write_file() and now a resume from that journal >> entry is triggering read_file() every time. > > You are right again. Perhaps we should add a read_metadata() method? > An alternative would be to have a 'datastore-loaded' method, but that > would be less consistent with the current API.
Hmmm, so if my activity needs it's preferences before it can display anything to the user, potential future lazy loading of the data-store (to try and speed up general activity start-up time) is going to leave folks watching my activity with a blank screen for a lazy while? Ouch. > But the determining reason would be that metadata properties other > than the custom ones are not preserved across reboots :/ > > http://dev.laptop.org/ticket/4662 Oooh thanks, double ouch, I hadn't spotted that gotcha yet! I'm getting the distinct feeling I should avoid current metadata interactions by an activity (too flakey and in transition just now) and just create a custom preference like file format, it only needs to store two key/value pairs at the moment, probably will eventually need only half a dozen at the most for future display options. Though I guess even that's still going to be a problem if lazy data-store loading is ever implemented (though every activity that needs to load a file for display will suffer there). Leave the metadata alone for the Journal and lower level activity class behaviours. Pity, metadata looked like a nice solution for storing simple custom activity state information, maybe in update. 2... Thanks again. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
