|
|
Rank: Advanced Member
Groups: Member
Joined: 12/23/2013
Posts: 114
|
I've seen you closed down this thread https://www.essentialobjects.com/forum/postst11054_EOWP-Fallback.aspxI can perfectly understand your position and I can also understand that you have to maintain your product but in this discussion you failed to answer one important question and I kindly ask for an answer. I can understand when you as a vendor reject a feature or fix but as a paying customer, I think I can request an answer to my fairly simple question: As mentioned in my previous thread, I found out that setting the property EnableEOWP to true cannot be reversed. Can you please explain to me why I can't just set it to false at any point in my code and get the same behavior as if I never set it to true. I've double checked the documentation and I couldn't find anything mentioning this bizarre behavior. Thank you, Stefan
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
Hi,
The whole application can only have a single process model --- either EOWP as true or EOWP as false and which model to use is determined when the first time a child process needs to be created. This means this value is only being used at that moment. Setting this value afterwards has no effects.
If there is anything in the documentation that is not clear enough, please feel free to ask. This is why we are here. However as a friendly warning, please do not attempt to hold the documentation hostage by stating because the documentation said such and such, so it must do this or because they documentation didn't say so so it can't do so. This is not how it works. Even as a paying customer, the documentation is only provided to you for your convenience and the product is provided as is. We have every reason to give you the best product/service we can possibly provide, but at the same time, as you already understand that it is not possible for us to give every single customer exactly what they want as different customers would almost certainly want different things in different ways. As a result, we can not afford to allow individual customer to dictate on how the product is implemented, so please do not attempt this in the future.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 12/23/2013
Posts: 114
|
Thank you for the explanation. This is very helpful.
For what it's worth, it was not my intention to "hold the documentation hostage" and it was also not my intention dictate how to implement the product. I was simply asking for an update in the documentation to make it clearer for your future customers that this is the expected behavior of this property. If I had known this, I would have saved hours of work, a custom build for my user and a lot of nerves. If you put this information in the documentation and clearly state that this property cannot be reversed for those reasons once a worker process has been created, would just be great.
The other feedback relating to crash/hang the entire application when a fatal error occurs was only to point out that this might be an area where you could improve your product. In my application I host many 3rd party components and none of them are "able" to bring down my whole app. I can understand that this might be a difficult or even impossible task for you to improve but I was merely pointing out that this happens. The comparison with the airplane is kind of lame. As I see it, if EO WebBrowser cannot work, it should be only affecting the web browser in my app, not the whole application. There are still many other components in my app which does not rely on EO WebBrowser. For me it's more like, if the airplane's entertainment system fails, it shouldn't bring down the whole plane ;)
English is not my first language and if I have offended you in any of my posts, I apologize - it was certainly not my intention. I may sometimes sound not so polite in my posts but I just wanted to have a professional, objective and constructive discussion on this matter.
Thank you!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
As to the documentation, as already mentioned, if there is anything that's not clear, you are always welcome to ask. We are always looking for ways to improve the documentation as well. So feedback is always welcome.
As to the entertainment system in the airplane, our position is you are the airplane designer and you are the one that's responsible to make sure the systems that you deemed not critical is well isolated from other critical system in your airplane. We provide a component for you. We do not provide an entertainment system for you. You are the one that decide whether to use our component as part of your not so important entertainment system or as part of your mission critical navigation system. It is not technical possible for us to decide the purpose of a component, or achieve isolation in the component level. It is common knowledge and practice that an unhanded exception always crash an application and it is designed this way. You can try to write a write locked file and you will get an exception that will crash the application. In this case it's not the File components responsibility to somehow try to find another way to still write the file successfully even if it locked. It is you the application designer's responsibility to act accordingly if you do not want your application to crash, or do not want other critical section to be affected. In your case, we believe it's fundamentally wrong for you to expect our component to isolate itself from other part of your application. This is the application's responsibility because it is only achievable on the application level, not the component level.
|
|