http://bugzilla.moblin.org/show_bug.cgi?id=10477


pohly <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|Undecided                   |P1
             Status|NEW                         |ASSIGNED
                 CC|                            |[email protected]
   Target Milestone|---                         |1.0




--- Comment #1 from pohly <[email protected]>  2010-04-14 02:07:38 PST ---
Now this one is going to be tricky. We cannot simply copy the whole environment
over to the daemon, and even setting a only subset for the complete process is
troublesome (affects whole process, not just a single session).

My proposal for a short-term solution:
- build a white list of "known" env variables (grep the source code)
- extend D-Bus API to transfer those
- set them temporarily when running the operation, remove again
  afterwards (can be done via list< boost::ptr<ScopedEnvChange> >)

Long term solution (please track as feature request in BMC if you agree):
- introduce a registry of env variables
- store them in the current session instead of using setenv()
- remove all direct "getenv" calls, route them through some
  code which knows about the current session and retrieves
  variables from there before falling back to getenv()

Caveats with that:
- if we allow backends to register env variables, then
  syncevo-dbus-server and syncevolution will have different
  entries in their registry => need D-Bus API call to retrieve
  server's registry
- "current session" is not always available in all function;
  a general problem, also needs to be solved for logging
  => introduce thread-local pointer?

-- 
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
_______________________________________________
Syncevolution-issues mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution-issues

Reply via email to