flexpw-planning Mailing List for Flexible Password Manager
Status: Pre-Alpha
Brought to you by:
berniebln
Menu
▾
▴
flexpw-planning — Planning discussion
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
|---|
|
From: Bernhard S. <ber...@us...> - 2009-12-02 00:04:36
|
Hello, some more thoughts on import and export. In order to make it easier to read, I'll write in the following my ideas about "export" - but everything applies to "import" in the same way. Since we have inhomogeneous data items, even unpredictable different because any kind of data item plugin could be written, an "export all items" method seems impossible, and we might have to provide an export method for every single type of data. For example, say we have the following data items (simplified): * password entries (name, password, url) * diary notes (date, memo) * PIN codes for bank cards (PIN, name of bank, number of card) * TAN-list for online banking (list of numbers) Let us say we allow the creation of groups, where any group might have other groups as children, and/or data items of one fix category. A user might have created the following data ([] marks a group) / |- [Passwords] | |- [Business] | | |- Company login | | |- Company remote login | |- [Private] | | |- instant messaging login | | |- email login | | |- some site login |- [Diary Entries] | |- [2009] | | |- 01.01.2009 | |- [2008] | | |- 31.12.2009 | | |- ... | | |- 01.01.2009 |- [Pin Codes] | |- Pin for my debit card | |- Pin for my credit card |- My one and only tan list While the password items could be exported to a CSV file, as well as the pin codes, that starts to become a problem for tan lists: they have one field with a list of entries, that cannot be exported in a row of a CSV file (well, at least not in a clean manner...) So for password entries, we could offer a CSV or TSV export, a text export, a HTML export, an XML export, ... For diary entries we might want to offer text export, HTML or XML, maybe PDF, ... For Pin codes, CSV/TSV would be good, text wouldn't hurt, HTML or XML would be good as well... Tan lists can be exported to text files, with one tan in each line, XML or HTML, ... So we see that in some cases, we can export to CSV, but in all cases, we can export to XML, and we could even assume that we can always export to HTML (for viewing data, or printing it out). So a possible architecture could be the following: For file formats that support joining of different data types, provide a "export all" menu entry, for file formats that can only carry one entry or a list of different entries of same type, provide extended "export some" menu entry. Some candidates for "export all" would be XML, HTML, Simple Text. Now any plugin is strongly encouraged to implement export functions for these types, to make it possible that all entries can be exported into a single file of the formats mentioned above. Some candidates for "export some" would be TSV/CSV: We could export all password entries into a single CSV file, and we could export all PIN codes to one CSV file, but we cannot export password entries and PIN codes together in a single CSV file. And for all kind of entries we might want to implement individual export functions, that for example export to the special file format used by other applications. I find this idea quite cool, but it can also lead to "messiness": Imagine we want to include PDF to the list of "export all" formats. That means that for every plugin, the PDF export function needs to be available. But if the plugins already exist, it is very likely that not all of them get updated by their authors. In this case, the "export all" method has to cancel with a "Sorry, not all entries can be exported using export all". Not very nice... My solution for this: Do not call the "export all" candidates such in the user interface :) If we just provide an "Export entries..." item, a wizard could support the user and explain which entries can be exported into which files. That can be automated of course, if the plugin architecture of data item plugins supports querying of the provided export facilities. Bernhard |
|
From: Bernhard S. <ber...@us...> - 2009-12-02 00:04:30
|
Hello there,
here are some design ideas I have about the general concept of the
application ("the app").
I like the idea of considering the app a universal store of private
information ("something") that are locked away in a file ("somewhere"),
protected by some means of encryption ("with some kind of protection").
In short: an app that stores something somewhere with some kind of
protection.
Cool - a Swiss Army Knife, we can store our passwords, our secret
thoughts, our diary, our hidden plans, our notes there, with adequate
interfaces for each of these different kinds of information. We could
store it in a local file, on a ftp server, maybe to a web app that makes
this data available to us through HTTPS over the internet, to our
mobile. And so many kinds of protection and identification: master
passwords, key files, using the fingerprint reader, eye recognition...
Unfortunately, if we want to implement all of these, there is a slight
chance that the planning phase will not be finished until 2020, and a
small possibility of a little loss of motivation might come along with
it also.
But why limiting the project to the storage of passwords only, if the
coding that has to be done to encrypt the data, to perform the
authentication etc. anyway?
In my opinion, the best idea is to establish a simple and
easy-to-understand plugin system:
* That will more or less automatically establish a good structure on
the core modules of the app
* It will make it easy to create first running prototypes
* If someone decides to extend the app herself, it will be more
encouraging to do that, because with a good plugin architecture, it will
be much easier to understand how to extend the app, and the coding goes
all into one plugin, that means, to one place - it will make it easier
to debug etc.
* Plugins can be shared, switched on and off - easy customisation!
I already see a Mozilla-like add-on library for FlexPW :))
Okay, back to reality. I think it would be a good idea to think of a
simple plugin design for the three core parts, that is,
* saving data encrypted to somewhere ("storage plugins"),
* authenticating the user by certain means ("authentification
plugins"),
* and modelling and displaying data ("data item plugins").
To the last point: any kind of data has to be stored into a python
object, and there must be a mask that allows the user to edit this data.
So if anyone wants to extend the app by, say, a possibility to save
diary entries, he or she has to define that a diary entry has a date and
a memo field, and for the edit mask, there should be a label and a date
picker to specify the date, and a multiline text area to enter the memo.
For the saving, it should be discussed whether Python pickeling is an
appropriate method to store the content of data item plugins. Otherwise,
we could request some special export function for internal storage by
these plugins.
As a first step, it might be a good idea to start with a light-weight
controller, that gets the three plugins assigned manually (later, a
plugin management can be written or imported from some library, if there
is anything like that).
I assume that even with some very simple sample plugins, we will already
gain quite a lot of knowledge about how to design the plugin
architecture.
I'm going to write another message about import and export architecture,
since it seems to be a little more complex.
Bernhard
|
|
From: Bernhard S. <ber...@us...> - 2009-11-30 22:29:31
|
Welcome everybody :) |
