Sync workflow data folders via Dropbox

[stuartcryan]

OK so I have been working on a new version of Clinton's "Tabs" workflow and it has got me thinking.

 

Currently I have a requirement to be able to configure persistent settings for that workflow and several other workflows including:

• My new version of Tabs (details of that to come later... working with Clinton on that)
• Asana Quicktask (Mannie Schumpert)
• AlfredTweet 
• (are a few that just come to mind).

Currently these store preferences in the appropriate folder under ~/Library/Application Support/... etc

 

However I am increasingly seeing a need for enabling workflows to have data that can be synced between computers. It would be great to just have ~Dropbox/AlfredSync/Workflow Data/{Same structure as under ~/Library/...} then enable workflows to use this location using something like {syncedData}/bundle.id/ (i.e. as a variable similar to {query} in each of the script workflow steps.

 

The alternate way is every workflow that wishes to enable such behaviour has to write a feature separately to manage this, manually changing the folder of only it's config but it seems like something that would be far more logical to have Alfred do (and far easier than having to write manual workflow steps to manage/update the configuration as I am currently seeing in my future.

 

Many thanks

LOOOOOVE Alfred.. IT RULES!

Stu

[jdfwarrior]

OK so I have been working on a new version of Clinton's "Tabs" workflow and it has got me thinking.

 

Currently I have a requirement to be able to configure persistent settings for that workflow and several other workflows including:

• My new version of Tabs (details of that to come later... working with Clinton on that)
• Asana Quicktask (Mannie Schumpert)
• AlfredTweet 
• (are a few that just come to mind).

Currently these store preferences in the appropriate folder under ~/Library/Application Support/... etc

 

However I am increasingly seeing a need for enabling workflows to have data that can be synced between computers. It would be great to just have ~Dropbox/AlfredSync/Workflow Data/{Same structure as under ~/Library/...} then enable workflows to use this location using something like {syncedData}/bundle.id/ (i.e. as a variable similar to {query} in each of the script workflow steps.

 

The alternate way is every workflow that wishes to enable such behaviour has to write a feature separately to manage this, manually changing the folder of only it's config but it seems like something that would be far more logical to have Alfred do (and far easier than having to write manual workflow steps to manage/update the configuration as I am currently seeing in my future.

 

Many thanks

LOOOOOVE Alfred.. IT RULES!

Stu

 

The workflow developers do this out of a "best practice". It prevented the workflow developers from having to detect whether or not Dropbox was installed, and then, the end user may want some custom folder for syncing the settings. It could be kind of a pain on their end so it was just recommended to keep settings within a local folder. That's not to say it can't be done another way. Alfred's isn't dictating where the data is written, the workflow developers are.

[stuartcryan]

Howdy David,

Thanks for the feedback. I can definitely appreciate the methodology and thinking behind why developers do this as a "best practice". I guess what I was identifying was, at the moment there *is* no standard and for workflows that do not need to store complex settings that is fine and they can be stored locally. However for workflows that require some sort of configuration it would be ideal to enable (if selected) the ability for settings to be synced.

 

I guess I see several ways of tackling this:

1. Workflow developers design a settings workflow as part of the workflow, which gathers and stores a new folder location to reference the settings (this then needs to be configured, per computer, per workflow). The downside here, is this would add increased complexity to workflows, these may be written in many different languages, and may work slightly differently between each workflow. It also requires the addition of a large portion of new code to workflows to enable easy definition of where it should store its data (i.e. to make it user friendly).

2. Community designs a "settings" workflow which standardises several such configuration settings, user then configures on each computer and other workflows can reference/leverage the configuration generated. Benefits here is things are standardised, if the workflow is leveraged correctly then a user should only have to configure it once for each machine. Downside is that this may use a language that not everyone is familiar with, requires workflows to rely on something that may or may not be there (i.e. settings workflow may not be installed).

3. Alfred adds a global setting which lets you specify a folder (separate to dropbox) where workflow data can be stored. It is then put forward as a new standard that before defining your data storage location you check if {datafolder} is specified (as an example) if it is, you use that as the base folder, if it is not, you use whatever folder you wish to specify. This would require a bit of smarts around it, for example if someone does not have it set, then later decides to, alfred should copy all the existing data to the new location. However this is far preferable having a standard supported mechanism to do so, rather than relying on each workflow to manage this behaviour itself.

4. Alfred automatically stores the data folders in Dropbox when Dropbox sync is selected. This is just another way of looking at it and may have pros and cons, it would expose in the same way the {datafolder} parameter which workflows could then check... if it is set... use that location (ie. into the dropbox folder) if it is not, then do as you wish.

 

With either option 3 or 4 I would also anticipate a flag that could be set on a workflow (i.e. through the gui, same page as the Workflow Details) which lets you flag it as "separate instance" i.e. even if you are syncing all the data, you want this computer's instance of the workflow to have its own settings, then Alfred would simply append to the {datafolder} parameter a computer UUID or similar.

 

I guess what I hinting to is... there is no currently supported and standardised mechanism to support the syncing of data for workflows that require it. I think a lot of the power of Alfred comes from it handling such heavy items under the hood. While it would be possible to do items 1 or 2 they are less than ideal and will likely result in some difficult to use/complex and non-standard workflows where as by putting some basics into the Alfred interface, the application can capture the detail of how the user wants synced settings to operated (which it already does but just not for the workflows) and expose that in a standardised and supported manner.

 

Look forward to your thoughts.

Cheers,

Stuart