|
[
Permalink
| « Hide
]
Alexander Peshkov added a comment - 05/Apr/16 02:05 PM
Being in general agree that a way to force use of embedded/server access is useful I want to point to the fact that with correctly administered access rights to database directory user who is not supposed to used embedded access (normally that's all users in case of SS except admins) should not have file access to databases at OS level and following this rule will solve most of your problems.
What about parameter - is appears extra complication. I would sooner think about net:// for any server access and file:// for embedded access.
with xnet and local ipc being brought together under "net" umbrella...
possible also there may be nested URIs like the one JayBird provides for OpenOffice.org I was thinking that making those options ( specifying protocol by URI and specifying isolation ) orthogonal would provide for more flexibility, allowing any combination of those options (or lack of) to be coded. Though I do not know if that would add practical value or this added flexibility would remain purely hypothetical. > with correctly administered access rights to database directory In some situations bullet-proof admins for FB is not what we can expect form real users. also it does not solve the reverse problem - "A requirement to use embedded server can not be manifested at all." ---- Then there is a question how to implement it in yvalve<->transport plugins interface. With a special option - one may add a single function to plugins interfaces: "AreYouEmbedded?()". Then if the option is specified in the CS/DPB the server when enumerating those plugins would just ad that call and filter plugins which gave result different from the provided option. With meta-URI it seems less straightforward to me. It asks for the inverted approach with some in-server (hardcoded?) list which plugins belong to "net" subset and which - to "file". So new transport-layer plugins would need changes in that central directory instead of implementing self-description call. ---- From mere user point of view though umbrella URI schemes might work too. Just I do not like "file" and "net" names - they seem confusing to me, specifying where the file is situated instead of specifying how server should interact with an application. "embedded://" and "isolated://" would look better to me. |