You should have no trouble using either that or IndexDB instead.ģ - people will want all of their data saved forever. We deliberately added the Lazarus icon to every field that was being saved so that it was significantly more difficult to use Lazarus for that purpose, but still many people asked for the feature.Ģ - we used an SQLite database with unlimited space to store the data. So here's some questions for you.ġ - decide very early on if you're going to save just individual textareas (easy) or whole forms (significantly more difficult).Ģ - are you going to encrypt the data? If yes, that makes it a lot better privacy-wise, but it also makes the database a lot harder to search.ģ - if you choose not to encrypt the data, then you'll have to make sure you don't save sensitive information like credit card details and passwords and such.ġ - the addon will get used by jealous people to spy on their significant others. And some of the other issues that you'll face when building this. Whilst I cannot build a replacement for it, I can certainly help you out with info about how we solved various problems. I'm really disappointed that it has been left to die a slow death, but I understand why this has occurred.Īnyhow, enough history. I had hoped that the other partner would have maintained the addons but he's had other hardships which have resulted in the addon never being updated since I left. When I left I gave full ownership of Lazarus to the other partner and agreed that I would to not make a competing product. Lazarus was owned by the business I worked for. Hi Chuck, I'm one of the original developers of Lazarus (and yes, we built it because we had a terrible version of trac that would keep logging you out when you submitted a new ticket, thus loosing half an hours work in an instant). A browser crash or power outage would almost certainly corrupt the database, so some sort of backup mechanism should be employed.Īt some point, I would require beta testers to help debug the extension. Also, storage is done asynchronously so no guarantees on how quickly it is done. Ideally, the database would be saved each time a field's value is changed, but this may impact performance. The database would have to store the URL of the page, the ID of the field, and the text content of that field. This includes the database overhead so the actual number of characters is less. Chrome extensions can only store 102,400 bytes in the cloud and 5,242,880 bytes locally. One potential problem would be the limitations WebExtensions sets on storage. A form fill recovery extension would also have to parse the DOM for input fields, but would save the field's value in a nonvolatile database. Paste Email Plus parses the DOM for all input fields and allows users to paste a predefined text string from a dropdown list. That extension has some similarities to what is being discussed here. Nonetheless, I was able to re-write one of my extensions (Paste Email Plus) to work with Chrome (Paste Email Plus for Chrome). I've already written three or four Chrome extensions with WebExtensions and have found it severely limiting compared to XPCOM. However, all the Fx extensions I've developed were with the soon-to-be deprecated XUL/XPCOM framework in favor of WebExtensions. I've been developing Firefox extensions for over a decade and am not new to the process. Since it has been over a year since any progress has been made, I guess we can assume that the new project has been abandoned.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |