[GRASS-dev] PROPOSAL: v.edit WAS: d.* commands

[Hamish]

Wolf:
> I agree I would also like to see this undo feature, and exit without 
> saving. the GUI part could simply store a queue of v.edit commands to 
> execute for the save part, and somehow put the drawn objects in a
> display queue. In the event of an undo it could simply remove the
> last item from both queues and then redraw the screen.
> 
> One concern I have before I start to design the interface, is that
> will it  be an expensive operation to execute an external program for
> each object to digitize? I mean the program will have to be launched,
> then it will do its thing and then it will recalculate the topology,
> right? I'm mainly wondering whether it would make sense to allow
> multiple edit commands in one go of v.edit? Would it increase the
> speed? On the other hand the v.edit commands can be executed in the
> background, and the user doesn't have to sit and wait for them to
> complete.

I think you answer the second paragraph with the first. 

Just like db.execute, input from a file is much faster than in a shell
loop as you can process multiple SQL statements at one time in a single
process. (and as Jachym suggested from stdin as well)


Jachym:
> I also thing, that XML is the way, GRASS should follow.

I do not agree. XML is good for complex constructs. For simple a,b,c
input flat ascii is much easier to deal with. i.e. for simple commands
would the XML overhead take up more bytes than the data?
I second what David has quoted from The Art of Unix Programming.


Wolf:
> Do we have an XML parser in GRASS?

No. If we need one, we should depend on a common external libxml.



Hamish