[Architecture] Saving preferences sets via the FlowManager?

Colin Clark colinbdclark at gmail.com
Mon Apr 21 10:53:46 EDT 2014

Hi Boyan,

On Apr 16, 2014, at 9:37 AM, Boyan Sheytanov <bsheytanov at asteasolutions.com> wrote:

> In the SmartHouses app, we would like to permanently save some application-specific preferences upon specific user actions. It seems that currently the architecture supports two ways of doing that:
> 	• Making a POST request to the Preferences Server directly at /user/%token
> 	• Making a POST request to the Flow Manager at /save/%token
> The latter was implemented by Yura as part of GPII-75 (see lines 105-118 in FlowManager.js) but it doesn't seem to be used anywhere outside the tests for it.
> The FlowManager /save API is not documented anywhere and the documentation for the Preferences Server doesn't reveal too much details (e.g. what is the expected format of the POST request data).
> My questions are:
> 1. Which API should we use for saving user preferences - directly to the Preferences Server or through the Flow Manager as a proxy?

Accessing the Preferences Server directly will increasingly be discouraged--and eventually removed entirely—for third-party applications. Our goal is to use the Flow Managers—the local Flow Manager for desktop applications and the cloud-based Flow Manager for web applications—as the primary point for accessing and saving preferences in the system. 

As far as I know, the /save resource is just a straight pass-through proxy to the Preferences Server at the moment, so its payload should be consistent with what you’d send to the Preferences Server.

I’m somewhat confused about the Smart House. Is it a native-style web application, or is it a regular “open it in your browser” web application? Can you point me to some documentation that describes how it is integrated with the Flow Manager, or to some source code?

> 2. Is there other documentation on these topics that I am missing? I know I can look directly at the code but that is time-consuming and not really welcoming to new developers.

I know the documentation isn’t great, and there’s a lot to be done here. Improving it as we go is something we’re all responsible for. I’m happy to provide pointers to the Smart House team members to get them started on contributing to the Cloud4all documentation.


More information about the Architecture mailing list