Storing tox profile

[unsane]

Let there be a vote 

[watcher]

Storing Tox profile inside Miranda DAT sounds like a good idea but in real world it is not 100% safe - it can bloat Miranda profile by megabytes - there is always exists such possibility, it might not to, but you can never be sure.

[Wishmaster]

I voted for  '%APPDATA%\Tox'  to keep it synchronized with other clients.

[watcher]

Wishmaster, all good, but it will kill Miranda's portability.

[Wishmaster]

Wishmaster, all good, but it will kill Miranda's portability.

Hmm.. good point. Can there be an option to choose between Miranda profile folder and Appdata?

[unsane]

Wishmaster, I can add folders plugin support.

[Vulpix]

I prefer it the way it is now.

A lot of speculations below, but some are actual real world scenarios.

For me, there are several major concerns:

- The plugin is not released yet, as such nobody can guarantee it won't corrupt my miranda profile
- If my profile is corrupted by this, how do you then "remove" the corrupted tox from it, in case there is an issue?

Or another scenario, consider you have a backup of your 64bit miranda and you have it on a 32bit machine just for backup reasons. Then your 64bit machine dies and then you want to just start your tox to make a call (because miranda itself does not have audio/video capability) and you cannot, because you need your profile for it, but you can't get your profile because it's somewhere inside your miranda DB, but you can't get miranda started to export it because you are on a 32bit machine and your miranda is 64bit.. you'd need to download 32bit miranda and then see about all of the plugins etc to get to even export it, and even then that c ould bring many issues and it could corrupt your own miranda profile too.

- I definitely think that having it in roaming is potentially dangerous. Imagine you start utox and then make some changes to the profile WHILST miranda is running. What would even be the state of that file afterwads? Not to mention using the same profile file from 2 applications / locations causes some really weird behavior. Or for example there is an API change to libtox and someone launches uTox which changes the structure of the tox profile and miranda is then unable to read it because it's different and somehow corrupts the file afterwards.

I think that if you wish to store the tox profile in the db then:

a) it must be safe, no way of causing damage to miranda DB. The tox profile is small enough (with 40 contacts it's still only several hundred kB), so that's fine
b) it has to be backwards compatible, i.e. if the tox file/profile is not in the miranda db, it should still be able to load it from the .tox file next to miranda DB (as it is now)
c) it has to store any changes made to the .tox file next to miranda db in case you want to use only the tox profile with a different client. Export function is nice but it implies you are able to start your miranda. For example, saving it on every miranda exit or on every profile change sounds like a good idea. You don't have to read the file, just flush the new info into it.


Some of these concerns would dissipate if miranda supported A/V calls but I believe this is planned for the next few releases so not for quite some time.

[Robyer]

Here are my few cents to this topic.

One question is: Store it inside Miranda's *.dat or not? I say no, because:
 1) Profile is just simple key=value repository. It doesn't store any binary data - no avatars, spam databases, no other files like that. Raping it by storing tox profile isn't right and will cause various troubles. Some of them Vulpix mentioned.
 2) Profile already contains contacts in Miranda format, it's not good to have them duplicated by having here also tox file with same contacts again.
 3) It's much easier to manage and to fix potential tox file problems and doesn't require changes in plugin code

Second question is: Where to store the tox file then? I say in Profiles folder next to *.dat file with Folders support to change it, because:
 1) It's Miranda way - remain portability, have everything in single Profile folder, ...
 2) Let user choice with Folders plugin if he wants to, but default should be the profiles dir (point 1).
 3) Having it in users will cause problems when you have more instances of different Mirandas (like testing and private one).
 4) Other problems as Vulpix said.

So keep it as is and just add Folders support. 

[watcher]

So keep it as is and just add Folders support. 

I have to agree with that and with Vulpix's points of view.

[White-Tiger]

I hope it's currently "%miranda_userdata%\Tox", if not, you should do that
Also, once you've added Folders support, it would be nice if old files could be moved automatically to the new path on change. (check if target folder is empty, otherwise inform user about conflict and manual move)

IIRC neither Folders nor other plugins do copy files from old path to the new one^^ That's pretty dumb

[watcher]

I hope it's currently "%miranda_userdata%\Tox", if not, you should do that

Now it's next to Miranda DAT without dedicated folder.

[Robyer]

Also, once you've added Folders support, it would be nice if old files could be moved automatically to the new path on change. (check if target folder is empty, otherwise inform user about conflict and manual move)IIRC neither Folders nor other plugins do copy files from old path to the new one^^ That's pretty dumb

This support should be added directly to Folders plugin, so if you have time...

[Wishmaster]

This support should be added directly to Folders plugin

I disagree. It will cause problems if that file is still opened by its owner, or if the owner doesn't update the path internally.

[White-Tiger]

or those config files store their path or are otherwise path dependent.. (such as relative paths to misc files)
Such a feature would be nice to have... so that users don't need to move files manually after Miranda shutdown (and likely delete the newly created ones) but is probably hard to implement right... well unless plugins do it themselves.. (which is some work.. Though Folders could offer a service to move files to the new place, and plugins can take care of stuff to do before. Maybe a callback on change that does this move depending on return value?)

edit: can called callbacks(events) actually return a value to the caller? So is it somehow possible that Folders can know every one who hooked ME_FOLDERS_PATH_CHANGED and get their return value if any?

[Robyer]

I disagree. It will cause problems if that file is still opened by its owner, or if the owner doesn't update the path internally.

Hmm, good point.

edit: can called callbacks(events) actually return a value to the caller? So is it somehow possible that Folders can know every one who hooked ME_FOLDERS_PATH_CHANGED and get their return value if any?

I don't think so. Maybe just add 2 callbacks into Folders and other plugins will register them (if needed) and do closing/reopening files there - like "beforeMove()" and "afterMove()".
And/or also provide parameter when registering Folders path, that plugin [dont] want to move them automatically?

Or could be possible to move the files/folders at exit/restart/start?

Hm, also here is problem with folders with bigger files - like received files, which could take long time to move (e.g. on different partition). So probably it's too much work with too small reward?