On Sun, Dec 21, 2008 at 4:32 PM, Brett Henderson <br...@bretth.com> wrote:
> Jochen Topf wrote: > > On Mon, Dec 22, 2008 at 10:03:58AM +1100, Brett Henderson wrote: > > > >> So the stack based approach is more flexible, but takes a few more > >> mental gymnastics to get it right. To be honest I haven't found it too > >> bad one I got used to it. > >> > > > > One problem seems to be that the command line is inherently linear and > > its getting longer and longer with more and more options. Maybe we have > > to get away from it and have some kind of command file. At least > > optionally. > > > It shouldn't be difficult to load tasks from a file. I could create a > new single hyphen option that specifies the name of a file to load the > configuration from. > > The only thing I'm wary of doing is creating another programming > language. So far the command line implementation has been easy to > maintain and bug free. > > The command file can use a different syntax that somehow shows better > > what it will do. I don't know how this should look, but in a file there > > are "two dimensions" instead of only one, so that could help there. > > > Most of my osmosis usage is fairly simple so I'm not well placed to come > up with a good solution here. If you have some ideas I'm happy to take > a look. > > Brett > I like the stack-based options. It reminds me of Reverse Polish Notation on my HP 48G (which was sadly lost). I don't think the problem is with the stack notation itself, but just with how the change affected the semantics of the apply-change task (and maybe other tasks that take streams of different types). That was what I was referring to when I suggested it may be too disruptive to change (by change I meant reverse the order of the arguments to the apply-change task, not change back to a queue system). Karl
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev