Hi all and thanks for the useful software.

We are 3 people working in the same lan and we need to share the same favorites informations (customer logins).
IS coud be very useful to have a location in a shared folder in wich save favorites login

thanks

Misano

Right now you can manually export/import favorites from the Favorites Manager to a shared path. However, the feature that it sounds like you want is coming up in a future release. It was going to be called "Settings/Favorites RemoteSync" but I'm thinking of renaming it to "Roaming RD Tabs Favorites" and "Roaming RD Tabs Settings" to be more inline with Microsoft nomenclature. Sharing should be possible, but there may be problems initially when dealing with conflicts (two users writing at the same time from different cached versions). I need to ponder further on this. But it WILL be coming!

Hi Tim

First of all, thanks again for all your efforts. We are loving RD Tabs. I'd just like to put in another vote for this functionality. It would really help us a lot. I know the road map shows "Settings and Favorites RemoteSync" is set for 2.4 but what's the chances of us convincing you to bring this forward please?

In response to your concern about conflicts, can I make some suggestions?

- First of all, it would be useful if you could require a password to edit and export the sync favourites (one global password to start off with is fine). This just means new employees won't have access to the stored password or exporting the favourite to a usb stick etc. But they have a connection they can use while in the office.
- Secondly, each record will have two extra fields only used by RDTabs. These could be "LockedForEditing" - True/False and "LockedBy" - String.
Then when a user tries to edit the record, you check if it is locked, if not, lock it. I recommend using the windows logon name as the name you put in the LockedBy field. When record is saved, remove the locks. When someone else tries to edit a locked record, show a message that it is locked by user {LockedBy}, unless the user trying to edit is = {LockedBy}. This means that if a user crashes out before you can unlock it, the next time he edits it, he can basically save it and unlock it.

I hope this makes sense.

Oh! Just another thought because I was thinking where you are going to store the shared favourites and your conflicts might be because of file locking. So how about putting it in a SQL DB. I can help with this if you like. It's a matter of putting the data into a table, and reading it back and if I can create the code that does this for you. You can then implement it into your software reading the returned data back and using it in a connection (as I assume you wouldn't want to share your source code 🙂 )

SQL is an EXCELLENT idea. I will definitely consider that. Favorites are stored in a serializable collection, so it is SUPER easy to just send the favorites collection to xml.xmlserializer and then you get the exported files. Is there a similar way to do that with SQL? I also know that SQL has a lot of XML parsing capabilities. Is there a way to have it take the RD Tabs XML format and convert that into a record in a table?

I will also provide a file-based way to do this. Putting a "Lockedforediting" and "lockedby" field won't pass the security muster. Anybody could go into the file share themselves and edit it by hand. The way I was thinking was to use NTFS to RD Tabs advantage. If the user is granted read-only access to the folder, they won't be allowed to edit in RD Tabs (nor by hand). Simple as that.

Additionally, my current line of thought is to have local favorites and global favorites, instead of trying to combine the two. This way you can create your own favorites, even if you are not allowed to save them to the remote store.

The advantage of SQL, obviously, is more granular control. Since we can grant insert, update, and delete separately, we can give granular permissions to different users.

SQL will probably be a ways off, but I might be able to bump up roaming/global favorites...

Is there a way to have it take the RD Tabs XML format and convert that into a record in a table?

To be quite honest I haven't worked with XML & SQL before but a quick google has brought up a couple of good articles.

http://www.15seconds.com/issue/050803.htm 
http://msdn.microsoft.com/en-us/library/aa258671 (SQL.80).aspx

Putting a "Lockedforediting" and "lockedby" field won't pass the security muster. Anybody could go into the file share themselves and edit it by hand. The way I was thinking was to use NTFS to RD Tabs advantage. If the user is granted read-only access to the folder, they won't be allowed to edit in RD Tabs (nor by hand). Simple as that.

The Locked* fields suggestion is only to prevent two users with editing permissions from trying to making changes to the same record at the same time. I wasn't considering it for security. There's no reason you can't use both methods. Plus if the text file is encrypted with the master password like the rdtsf file then I am sure it will be secure enough.

Additionally, my current line of thought is to have local favorites and global favorites, instead of trying to combine the two. This way you can create your own favorites, even if you are not allowed to save them to the remote store.

I took it for granted that this is the way it would be. RemoteSync (or Roaming Favourites) would be an addition to local favourites which would carry on working as it does already.

I might be able to bump up roaming/global favorites...

If I/we can help in any way to get this moved closer then please let me know.

Locking parts of a file can get really tricky, especially since this a text file format and not binary, so the records vary in size. When somebody is editing global favorites, I will probably lock the entire file (using NTFS read/write-locking) and when they are done it will be released. During that time, syncronizations just won't happen. It's not ideal, but I think it will work until a more robust SQL-based system is developed.