Closed reki2000 closed 8 years ago
Hey.
Just to clarify, what I was referring to with part/service/service group, is to store that information in the database, not in Octoparts' config/settings. As this has nothing to do with Octoparts in general, but rather particular parts in specific, this information should be stored in the database, just as part information is stored.
If I understand you correctly, you want to try this first with config only. In this case, we can just deploy the branch with the changes locally. In this case, perhaps we should continue this discussion internally, rather than on GitHub. What do you think?
You have something to hide? huh? :shipit:
@mauhiz :speak_no_evil:
@mauhiz Top-secret level 9000 classified plans. I've already said too much.
Closing this for now to prevent accidental merging
Thank you for reviewing!
Done:
Progress:
@lloydmeta , As for using repository to keep proxy settings, I suggest that this time how about introduce this feature (with application.conf) as "experimental" state.
Because @xevix is also telling that setting might be more flexible, I agree with that idea, but I need to try this feature on our testing environment to check if it works as expected (including tester operation).
I guess we'll have another finding from that operational test.
EDIT: I thought that if using in "experimental" state, changing client API might be affects too much(newRequest supposed to require proxyId) . Another idea is to use "additionalHeader" argument to specify proxyId by "X-OCTOPARTS-PROXY-ID" header. This doesn't need updating octoparts jar in client application.