Am 09.09.2013 19:58, schrieb Robert Osfield:
Hi Sebastian,
On 9 September 2013 17:34, Sebastian Messerschmidt
<[email protected]
<mailto:[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.
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?
My solution takes care of making the new, in my eyes preferred way,
optional in order not break user code.
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 ;-)
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.
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
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
