<br><br><div class="gmail_quote">On Fri, Sep 30, 2011 at 7:29 AM, Pierre Racine <span dir="ltr"><<a href="mailto:Pierre.Racine@sbf.ulaval.ca">Pierre.Racine@sbf.ulaval.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ok Bryce. So I will invite people who have the need and time to implement new SQL functions to consider using your iterator. Hopefully they will have the time to understand it and they will have the faith that this is the way to go. I thought it was your responsibility to demonstrate its usefulness, not just in theory but also in practice but I understand that you have more important things to do. Unfortunately me too.<br>
</blockquote><div><br>You seem to hear only what you want to hear. Yes I will discuss the APIs, but separately. Usefulness in theory was demonstrated on the wiki page. Usefulness in practice was demonstrated with the existing tutorial. And I offered to write you another one on a different topic, which most people would take as signs of a continuing interest. It's positively bizarre that you interpreted that in the way that you did. I'm putting the brakes on because you're not on the right wavelength yet. <br>
<br>It is my responsibility to make sure that you (project leader) understand at least the intended function and the overall approach. If you want to know the details, you can plunge in and I can point you towards whatever you're interested in. I'm not so concerned that you have a mastery of all facets of this, but you should have a good conceptual grasp of how this could affect future choices about how to implement whatever function signature pops to mind next month or two years from now. <br>
<br>Intended function: provide a framework which supports the development of functions which return a raster<br>Approach: using best practices (encapsulation, separation of concerns, and limited polymorphism), create many small islands of functionality which perform common tasks (reprojection, expression evaluation, etc.), assembling them into a variety of processing chains which accomplish the desired tasks <br>
What does this replace: nothing.<br>How does this impact the user-visible API: it doesn't<br>
What plans does this alter: implementing all raster returning functions by calling one of two giant mapalgebra (1 raster and 2 raster) functions which share no code, each of which contains all the functionality required by any potential caller. <br>
What benefits can be expected: faster development, easier maintenance, fewer bugs, creation of new functions without the danger of breaking existing ones<br><br>Go ahead and ask me why I didn't just say that before. Watch my head explode.<br>

<br>I can work with Bborie to create the two raster version of mapalgebra using this framework if he likes. Maybe he can teach me about the strange looking testing framework we've got here...(I've only used junit and pyunit, which are essentially the same thing). For that matter, I'm also going to have to learn how to query the database from server side C code. Thus far I eeeked by using proj4, geos and gdal. This will be something new. I'm off at a workshop most of next week, but after that I can work this in.<br>
</div></div>