Jody Garnett ha scritto: > Andrea Aime wrote: > Don't follow you about generating code? The Transaction format is quite > clear though - broken down into delete, update, add ... think this one > is perfect. If you want to talk further I suggest we make a real example > and work through both approaches; and then probably write an example > parser (are you targeting a Java application programmer or AJAX here?)
What I meant, the clients does not have parsing code for Transaction already in place, just the code that makes Transaction requests. If we call this GetDiff response format "transation", I'm only saying that we have either to provide another one that's easier to deal with when you want to _show_ the differences, because otherwise we force clients to parse that stuff and apply it to features for revision M in order to show those at revision N... basically we're making the client do the same work as a server, no? >>> This is consistent with Galdos cascading WFS-T approach and would be >>> a *great* benefit for keeping servers in sync. >>> (Please consider this idea). >> I don't follow you... why Galdos matters in a GetDiff request? > Because they have covered this territory before us; and thus we can say > the idea is implementable - and better yet deployed. Sob... Jody, you are assuming that I know Galdos products, but they site is full of marketing fluff an no technical stuff, so I simply turned it down as useless. From your comments, I gather they have versioning already? Or what? >>> Rollback - don't do it, use GetDiff >> I disagree here for two reasons: >> * doing a rollback in the server is very quick, it's just a matter of >> a couple of queries (much faster, the more the bigger you revert is) > Ah you putting your performance concerns before the design; I had hoped > not to introduce any more concepts for users to concern themselves with. > Having operations that slot together etc... My point of view was the opposite. IMHO, not having transaction may save work on the client side, but makes life harder for the client. Rollback it's already in the vocabulary of users, and when you go and try to do it you've always have to deal with some other concept (dance of doom in cvs, reverse merge in svn). >> * if the rollback is big, the transaction request to do the actual >> work can be a huge gml document. > Like this point; at least *define* the service in terms of being exactly > the same as getting the difference and applying it using transaction > (makes the description very clear). Hum... I think I like the concept but I can't imagine what it would look like. I was thinking, having the equivalent of svn merge (directly opearting on the server) would not be bad... so, would a new Transaction element designed to do merges work? Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
