Coming soon...

[Eric H. Jung]

The first release won't actually "synchronize" settings; it will provide a way for you to store settings remotely.



Click for larger image.

[Miquel 'Fire' Burns]

How will this work exactly?

BTW, I'm still resetuping up my computer, so don't expect me to be around much.

[tanstaafl]

Hi Eric,

This is getting exciting - I'm really looking forward to this functionality, as I'm sure are many others...

That said, here are my comments based solely on the screenshot you provided. I know this is just a screenshot, and also this is a first implementation...

1. I'd go ahead and design the UI bearing in mind this functionality will at some future point in time allow for multiple sites. So, have the sites listed in a list view, with some way of informing the user that currently only Passwordmaker.org is supported (I strongly recommend we limit it to PM's site until as many bugs as possible are worked out).

2. If I check the 'Use Passwordmaker.org' checkbox, does this prevent me from assigning another Site under the Host settings, or will these be greyed out? Basically, once this is fully functionaly, the 'Use Passwordmaker.org' option should be in addition to any user specified sites, but initially, I think it should be the *only* supported site, other than local copies (see below).

3. I will not use this functionality until it supports secure protocols, so...

What protocols is this going to implement (initially? later?)? FTP? SFTP? SCP? Will MD5 (or other( checksumming be used to validate the downloads?

4. I'd also really like to see PM *automatically* make a backup copy (encrypted) of the RDF file before replacing the local copy with a downloaded remote copy - just in case something gets corrupted during the file transfer - and I think this is *especially* important to implement *before* we start playing with saving settings online, as bugs are worked out of the process.

This way, if something does happen, we can always revert to the local backup. This 'local emergency backup' could be prompted for if PM ever starts up and has a problem reading the RDF file.

5. I'd also like to see the ability to define *local* director[y][ies] for backing up an encrypted copy of the RDF file - at least one, but no reason not to allow for multiple local copies, and even multiple versions. This functionality could be integrated with the 'emergency backup' referred to above.

By multiple versions, I mean, an option to 'keep x copies', so that PM would that many copies before replacing the oldest ones.

Thanks as always for all your hard work on PM!

[Eric H. Jung]

Hi,

I'd go ahead and design the UI bearing in mind this functionality will at some future point in time allow for multiple sites. So, have the sites listed in a list view

I've already thought of this and although the back-end upload code supports it (not download), I hadn't written the front-end to reflect it. Not sure if I will for the first release, but I'll try.

If I check the 'Use Passwordmaker.org' checkbox, does this prevent me from assigning another Site under the Host settings, or will these be greyed out?

Currently, yes, but when multiple sites are supported--no. Use of the passwordmaker.org server will not be free.

What protocols is this going to implement (initially? later?)? FTP? SFTP? SCP? Will MD5 (or other( checksumming be used to validate the downloads?

The supported protocols are those native to Gecko--FTP and HTTP, HTTPS via WebDAV.

I'd also like to see the ability to define *local* director[y][ies] for backing up an encrypted copy of the RDF file - at least one, but no reason not to allow for multiple local copies, and even multiple versions. This functionality could be integrated with the 'emergency backup' referred to above.

By multiple versions, I mean, an option to 'keep x copies', so that PM would that many copies before replacing the oldest ones.

This will be available as a value-add if the user decides to use the passwordmaker.org server. IOW, passwordmaker.org will maintain a database of users' past RDF files. The user can view them, add to them, delete them, merge from them at will. The MD5 checksum feature will also be a value-add available only from passwordmaker.org. However, you should be aware that FTP and HTTP/HTTPS run over TCP/IP, which defines its own robust error handling and error correction algorithms. Use of passwordmaker.org for features will not be free and will be subject to the user's agreement of a disclaimer. Additionally, as a security precaution, passwordmaker.org won't accept RDF files which contain master passwords.

'd also really like to see PM *automatically* make a backup copy (encrypted) of the RDF file before replacing the local copy with a downloaded remote copy

I'll consider this, albeit probably not encrypted -- hey the primary passwordmaker.rdf isn't encrypted.

edit: Just to clarify, basic FTP/HTTP/HTTPS upload and download will ALWAYS be free!

[tanstaafl]

I'd go ahead and design the UI bearing in mind this functionality will at some future point in time allow for multiple sites. So, have the sites listed in a list view

I've already thought of this and although the back-end upload code supports it (not download), I hadn't written the front-end to reflect it. Not sure if I will for the first release, but I'll try.

Definitely not critical to the first release - especially if the back-end support is there.

If I check the 'Use Passwordmaker.org' checkbox, does this prevent me from assigning another Site under the Host settings, or will these be greyed out?

Currently, yes, but when multiple sites are supported--no.

Use of the passwordmaker.org server will not be free.

Good! Glad to hear it. I truly hope millions of people sign up and slam your servers so hard you have to buy a farm of eServers to handle the load! ;)

What protocols is this going to implement (initially? later?)? FTP? SFTP? SCP? Will MD5 (or other( checksumming be used to validate the downloads?

The supported protocols are those native to Gecko--FTP and HTTP, HTTPS via WebDAV.

Ok - so, HTTPS is the only secure protocol that will be supported? As long as there is at least one... although I'd really like to see support added for WinSCP at some later time...

I'd also like to see the ability to define *local* director[y][ies] for backing up an encrypted copy of the RDF file - at least one, but no reason not to allow for multiple local copies, and even multiple versions. This functionality could be integrated with the 'emergency backup' referred to above. By multiple versions, I mean, an option to 'keep x copies', so that PM would that many copies before replacing the oldest ones.

This will be available as a value-add if the user decides to use the passwordmaker.org server.

IOW, passwordmaker.org will maintain a database of users' past RDF files. The user can view them, add to them, delete them, merge from them at will. The MD5 checksum feature will also be a value-add available only from passwordmaker.org.

Ok, I see where you're going with this... and I don't really have a *huge* problem with it, however...

Even if you don't allow for the user to keep multiple backups of their RDF file locally (although, if you're going to allow this (multiple copies) for our own online setups, why *not* provide the ability to have local copies too? Just have two tabs: Online Repositories, and Local Repositories - Local would be much easier to implement than Online, no?), at a bare minimum I think PM should provide a single internal emergency backup copy of the RDF file during an online update or a merge process, etc, with the ability of the User to 'revert' to the previous version if something 'bad' happens - ie, if PM tries to load the RDF file and it is corrupt, it should simply prompt the User to load the last known good RDF file (showing them the list of dated files available if there is multiple Local file support).

This will add a level of comfort, at least for me - especially when you start implementing true synchronization (merging, import/export of single/groups of accounts, etc), as that will introduce yet another level of complexity and more room for file corruption.

However, you should be aware that FTP and HTTP/HTTPS run over TCP/IP, which defines its own robust error handling and error correction algorithms. Use of passwordmaker.org for features will not be free and will be subject to the user's agreement of a disclaimer.

But of course... ;)

Additionally, as a security precaution, passwordmaker.org won't accept RDF files which contain master passwords.

Good. I'd have a problem with that if it did...

I'd also really like to see PM *automatically* make a backup copy (encrypted) of the RDF file before replacing the local copy with a downloaded remote copy

I'll consider this, albeit probably not encrypted -- hey the primary passwordmaker.rdf isn't encrypted.

No - but I thought that was a feature request... and if it is not, it is a feature I'd like to see, since the Account Settings are the other major factor with respect to the calculation of the password. If someone gets ahold of my RDF file, they're halfway there, and I'd prefer to make it as difficult as possible for them.

edit: Just to clarify, basic FTP/HTTP/HTTPS upload and download will ALWAYS be free!

Can't ask for more!

Thanks again Eric - looking forward to testing this stuff out...

[Eric H. Jung]

Good! Glad to hear it. I truly hope millions of people sign up and slam your servers so hard you have to buy a farm of eServers to handle the load!

I was only trying to recoup expenses, not make money. If you think it's a bad idea to charge for that service, let me know and I'll reconsider. I'm really not interested in having passwordmaker.org slammed with bandwidth and leaving me to pay the bill.

although I'd really like to see support added for WinSCP at some later time...

I understand and will do my best to introduce it in a future release. You have to understand that I'd probably have to implement the protocol myself--from scratch. That's not trivial.

why *not* provide the ability to have local copies too? Just have two tabs: Online Repositories, and Local Repositories - Local would be much easier to implement than Online, no?

It requires MySQL, a webserver, and PHP. So as long as someone wants to run all of that locally, they could use the server-side code themselves instead of using passwordmaker.org. I will change the GUI so "passwordmaker.org" isn't hard-coded and you can always provide your own hostname. Perhaps a better term is "managed" vs. "unmanaged" hosting. Managed includes the database system; unmanaged is just upload/download to/from a file system.

at a bare minimum I think PM should provide a single internal emergency backup copy of the RDF file during an online update or a merge process, etc, with the ability of the User to 'revert' to the previous version if something 'bad' happens - ie, if PM tries to load the RDF file and it is corrupt, it should simply prompt the User to load the last known good RDF file (showing them the list of dated files available if there is multiple Local file support).

This is a good idea, I'm just not sure if I'll be able to get all of it into a first release. I can have the first release do a local backup of the RDF before download, but the user prompting bit might not be there...is that acceptable?

[tanstaafl]

Good! Glad to hear it. I truly hope millions of people sign up and slam your servers so hard you have to buy a farm of eServers to handle the load!

I was only trying to recoup expenses, not make money. If you think it's a bad idea to charge for that service, let me know and I'll reconsider. I'm really not interested in having passwordmaker.org slammed with bandwidth and leaving me to pay the bill.

You must have misunderstood me...

If you recall, I was the guy who *suggested* that you do this and charge a fee... nominal is ok, but it should be enough to pay for all expenses, and if it gives you some spending money too, well then all the better.

My joke about being slammed with bandwidth was with respect to *paying* users, which would give you plenty of money to provide the bandwidth necessary, and give you even *more* spending money.

As long as you are providing a valuable service - and the users themselves will determine that - then I see nothing wrong with you making some money in the process - on the contrary - I think it would be a *good* thing - especially if you allow those users who'd rather do it themselves to do so. PM is the greatest thing I've come across online in a while, and you'd deserve every penney.

although I'd really like to see support added for WinSCP at some later time...

I understand and will do my best to introduce it in a future release. You have to understand that I'd probably have to implement the protocol myself--from scratch. That's not trivial.

Hmmm... guess I was wrong - I was just thinking you could make this functionality require the presence of WinSCP, and just let it do the work.

why *not* provide the ability to have local copies too? Just have two tabs: Online Repositories, and Local Repositories - Local would be much easier to implement than Online, no?

It requires MySQL, a webserver, and PHP. So as long as someone wants to run all of that locally, they could use the server-side code themselves instead of using passwordmaker.org. I will change the GUI so "passwordmaker.org" isn't hard-coded and you can always provide your own hostname. Perhaps a better term is "managed" vs. "unmanaged" hosting. Managed includes the database system; unmanaged is just upload/download to/from a file system.

Thats what I was thinking - local storage on the filesystem. Just let the User specify a Local Directory (UNC support would be good), and then just have some way of date/time stamping the files.

at a bare minimum I think PM should provide a single internal emergency backup copy of the RDF file during an online update or a merge process, etc, with the ability of the User to 'revert' to the previous version if something 'bad' happens - ie, if PM tries to load the RDF file and it is corrupt, it should simply prompt the User to load the last known good RDF file (showing them the list of dated files available if there is multiple Local file support).

This is a good idea, I'm just not sure if I'll be able to get all of it into a first release. I can have the first release do a local backup of the RDF before download, but the user prompting bit might not be there...is that acceptable?

Sure, as long as there is a simple way to revert if something goes wrong.

Hope this was more clear...

[Miquel 'Fire' Burns]

Maybe have a way for a user to download the PHP code and install the online update thing on their own site?

[Eric H. Jung]

Maybe have a way for a user to download the PHP code and install the online update thing on their own site?

Yep. Open source rules.

If you recall, I was the guy who *suggested* that you do this and charge a fee... nominal is ok, but it should be enough to pay for all expenses, and if it gives you some spending money too, well then all the better.

My joke about being slammed with bandwidth was with respect to *paying* users, which would give you plenty of money to provide the bandwidth necessary, and give you even *more* spending money.

As long as you are providing a valuable service - and the users themselves will determine that - then I see nothing wrong with you making some money in the process - on the contrary - I think it would be a *good* thing - especially if you allow those users who'd rather do it themselves to do so. PM is the greatest thing I've come across online in a while, and you'd deserve every penney.

OK, thanks

Thats what I was thinking - local storage on the filesystem. Just let the User specify a Local Directory (UNC support would be good), and then just have some way of date/time stamping the files.

We'll see. I was saying that the filesystem might only provide 1 level of "history" or backup and if you wanted more advanced features, you'd need the server-side code and database ("managed") stuff. Could multiple versions be stored on the filesystem? Sure. Do I want to implement both that AND the server-side bit? Not initially, at least. Clearly all of these feaures and things must be phased in.

Hmmm... guess I was wrong - I was just thinking you could make this functionality require the presence of WinSCP, and just let it do the work.

What about non-Windows users? And shelling out to a command-line exe isn't a very elegant solution...anyway, we'll see. SCP of SFTP might be easier to implement than I think. The FireFTP extension has a native implementation of FTP...

[tanstaafl]

Thats what I was thinking - local storage on the filesystem. Just let the User specify a Local Directory (UNC support would be good), and then just have some way of date/time stamping the files.

We'll see. I was saying that the filesystem might only provide 1 level of "history" or backup and if you wanted more advanced features, you'd need the server-side code and database ("managed") stuff.

If thats the way you wind up implementing it, I would not be unhappy - but this has been discussed in some detail previously, and one of my suggestions was to implement the local filesystem backup support *first*, in order to work out the UI and related bugs - *then* add online support (since most of that work would be back-end Database stuff anyway). It's just that, to me - a non-programmer - it looks like local filsesystem support would be much easier to implement, and would be the best way to flesh out the UI for managing multiple sites (directories)and files on each site.

Could multiple versions be stored on the filesystem? Sure. Do I want to implement both that AND the server-side bit? Not initially, at least. Clearly all of these feaures and things must be phased in.

Of course this must be phased in - I hope you didn't think I was suggesting anything else, and all of our previouse discussions made this quite clear.

Hmmm... guess I was wrong - I was just thinking you could make this functionality require the presence of WinSCP, and just let it do the work.

What about non-Windows users?

? Doesn't every OS in existence (actually being used, that is) have more than one command-line capable tool that could do the job? If it were me, I'd implement this with a plug-in type approach, so that aanyone copuld use whatever tool they wanted to do the actual transfer/work (as long as they were willing/able to write the code to support it), and just let PM handle the front-end stuff.

And shelling out to a command-line exe isn't a very elegant solution...

You'd definitely know better than me... :)

anyway, we'll see. SCP of SFTP might be easier to implement than I think. The FireFTP extension has a native implementation of FTP...

And the new version (not released yet) supports SSL, so maybe that will help you do a native implementation...

Whatever you wind up doing will be more than sufficient, I'm sure. I'm just trying to throw out some ideas... I had a breather for a day or two, but I'm getting ready to get swamped again for another month or two. And on top of everything, it looks like we're moving our office next month (yuck)...