Boris Schaeling wrote:
On Fri, 10 Sep 2010 05:02:54 +0200, Jeremy Maitin-Shepard <jeremy@jeremyms.com> wrote:
Furthermore, it seems inconsistent that certain things are part of the "reusable" context, like the environment and process_name, but other things, like the executable path and arguments, are not.
So far reusing a context means launching the very same application a second time. This didn't work first with the stream behavior class hierarchy but works now with the delegates.
Is there much demand for launching the same process repeatedly? Even if so, that doesn't fit my idea of a "context." To me, "context" would capture things about the current process. What you've called "context" seems much more like "child_process" to me. Have I missed something?
Once we start to support platform-specific features the question is where do we end? The context class in previous Boost.Process versions grew more and more as support for uid, euid, gid, eguid, chroot etc. was added. Instead of arguing about each and every feature whether it's justified to hardcode it into the library we decided it might be better to support cross-platform features only and provide extension points.
The answer to what should be included and not should be based, in part, on how common the need proves to be. That is, rather than be biased against something because it isn't portable, consider whether the library can be truly helpful. Even if the feature is unique to one platform, if the library can offer valuable support for a feature used regularly on that platform, then supporting that feature in a platform-specific namespace would be helpful. Once you allow for platform-specific functionality, there can be demands for a great deal that diverges wildly among the supported platforms and leaves relatively little in the cross-platform portion, so caution is still needed. However, if much of the platform-specific support is merely by providing hooks into the library's behavior, such as the callback I suggested for creating a process, then there shouldn't be too much need for platform-specific functionality in the library. That is, you can allow such functionality but quite possibly preclude the need for it via customization hooks. The customization hook approach also leaves wide open what the library client can do, provided it can be done within the constraints of the interface provided.
- I think it would be cleaner for the POSIX and Windows extension interfaces to be in the form of a callback function (templated or boost::function), rather than a subclass of context that overrides the setup function.
Makes also sense to me!
Perhaps you both were thinking of what I've been suggested herein and in my other reply, though I'm not quite certain. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.