On 9 September 2013 18:30, Sebastian Messerschmidt < [email protected]> wrote:
> Am 09.09.2013 19:58, schrieb Robert Osfield: > > Hi Sebastian, > > > On 9 September 2013 17:34, Sebastian Messerschmidt < > [email protected]> wrote: > >> No offense, but this feels more like a hack than my solution. >> > > Indeed, but it's hacks that external to the core OSG done for a very > specific end user purpose, rather than hacks in the core OSG for a very > specific end user purpose. The OSG has many users and many different usage > models, internalizing all these usage models is in-inappropriate. Would > you have me merge every little whim of the community or only should I be > beholden to just your whims? Or should I try to make sure that any core > modifications are fully justified? > > I surely don't want to argue with you, but I simple do not see where it > hacks the core. I somehow feel that it simply breaks the rules of deferring > it to a callback. > Perhaps you should review the code if you don't think it's a hack... It's a crazy partial disabling of an existing behaviour. It only makes sense in the context of what you are doing, other users coming along won't realize what the code is there for and how it's intended to be used. It's only once you add the magic of what you are doing in your application that it can make sense, even then it's not quite sensible. > The point is, that the original solution simply does not move any > information to the outside. I agree that is not the cleanest solution to > open up multiple code paths here. > What I don't get is the initial design. In my understanding it is bad > design not to call the original implementation (i.e. findFile), as a user > adding callbacks will fail. So chain of responsibility is broken here. > One could have the OpenFlight plugin defer to finding files to the image plugins, some plugins do this - for instance native OSG formats simply do a readImageFile() without forcing the find path. Changing OpenFlight across to not doing it's own findDataFile() would potentially break user code though if an image plugin doesn't both doing a findDataFile(). If one was to make something optional that it would be the findDataFile() call, it wouldn't be the ignoring the result of the file call. So we agree. It should defer it, but it doesn't. I don't get the last part > however. Can you elaborate how it would break? > Any change in behaviour has the potential for breaking existing users applications, changing something as fundamental as the find behaviour is something that clearly could have repercussions to end user application code. > My solution takes care of making the new, in my eyes preferred way, > optional in order not break user code. > Forget your solution. It's a hack and rejected in it's current form. > > > >> >> You are right however: Passing the information would solve my problem >> since I only need to know which files are missing. >> Also I want to point out that I'm not the only person having this problem. >> > > Having more people wanting a hack to be merged into the core OSG doesn't > change the fact that it's a hack. We can and should do better where we can. > > You are right. I simply don't feel very comfortably with the > "FILE_NOT_FOUND:filename" solution. But maybe we can raise this to a higher > level to make it cleaner. > I'm open to suggestions, but I'm still not convinced that the presented > solution is evil ;-) > It's isn't evil, but it is bad programming solution. I want to see the code base improving over time not steadily going downhill. > > A question: In terms of following the unwritten rules - attaching > callbacks is meant to defer resolution of such errors to the user. The > plugin handles this in a very strange way. So the presented solution makes > it more the way it was intended. > The plugin isn't really behaving that strangely, it searches for a find and if it can't find it it doesn't attempt to load it. The only thing missing is that you want to do something extra which is not the usual usage model. The implementation isn't only strange when viewed from your application specific needs. > Right? > Then we could use the callback pattern over the current implantation and > make the old behavior optional and see how many people's code it is > actually breaking.;) > > Let me know if you can think of a viable solution > Having an option to disabling the local findDataFile() calls and instead relying upon the image plugins to handle the find is something that I'd be open to do. Making it the default is not something that feel comfortable with at this point. We'd have to do big call for testing from OpenFlight users to find out whether this change of behaviour would introduce any regressions. Robert.
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
