Am Dienstag, 1. Juli 2014 14:05:39 UTC+2 schrieb David Rajchenbach-Teller: > Let's concentrate on Session Restore for the moment.
OK, it was just because of the example and the need for a "Journaled Storage" ... > Adopting a Journaled Storage will let us decrease the total amount of > I/O. Once we have sufficiently fine-grained differential updates, either > Journaled Storage or Sqlite would allow us to change only a single tab > (or even a single attribute). Both Journaled Storage and Sqlite also > need to consoldate their data. Yes. But as far as I understand it (and I can surly be wrong), a SQLite-DB is always the same file. It grows, consolidate, maybe shrinks ... but always the same file on "the same place" ... Working with sequential files creates always for some changes a file with this changes, then creates a new one for the next changes ... then consolidate, delete the old ones, creates a new and new files for the new changes ... A lot of files gets written and then deleted again ... the file system creates new files always on that places, that was deleted first ... this is fragmentation ... the more files that gets written and deleted again, the more fragmentation ... the head of the HD starts to "jump around" between the files, need energy, need time, make the access slow ... Also a lot of small files waste a lot of unused space, because of using always complete blocks on the HD ... > It is possible that Sqlite would be more efficient than Journaled > Storage for this use case. At this stage, I cannot tell. However, it is > certain that Sqlite would kill all existing add-ons and recovery > mechanisms for Session Restore, while Journaled Storage would not, so > Sqlite would need to be much, much better than Journaled Storage to > justify such a migration. I'm not really a programmer and I'm not really involved in the source ... but whats about of a kind of "abstraction layer" ??? At first all can stay the same then before, just the ASCII File will be replaced with a SQLite File with one table with one field. This should remove that always the file gets new created (written). As far as I understand, a ASCII File will be always new written, getting a new place on the HD, right? An SQL File will be updated ... Later the cell can be spited / redesigned ... New APIs to write to the new cells ... The old API can be changed to trigger the new APIs ... ... and then should all be down-version compatible ... The old APIs can then be "deprecated" ... So, as I'm said, I don't be involved in the code of FF ... Is this much more work/harder then do the changes for the "Journaled Storage" ??? FF is for the open web ... OK, a "Journaled Storage" is maybe readable with an ASCII Editor ... but not really a standardized file format ... not much usable for a power user or admin ... difficult for an programmer ... ... an SQLite DB can be opened, used, converted with a lot of programs ... I think even LibreOffice can open it ... I used for the Places DB this one: https://sourceforge.net/projects/sqlitebrowser/ It's not that I persist on SQLite! It should be just a discussion about the pro and contras of it ... > Cheers, > > David Greets, Tobias. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
