Jo Walsh wrote:
dear Chris, thanks for your prompt and full response,
On Mon, Nov 27, 2006 at 06:37:16PM -0500, Chris Holmes wrote:
I would love it if we could include our ideas on transactions and
versioning and the like in WFS-Simple, but unfortunately I do fear that
when you get in to transactions, authentication, and versioning you're
no longer in 'simple' land (indeed I myself might argue against their
place in a simple spec).
Then 'Simple' is kind of a misnomer. 'Basic' was the original name,
right? I would have thought being able to write a feature to a web
feature service was a fairly basic operation ;P
Yeah, I agree, that'd be nice.
You don't need much of the rest of WFS, right, to do Transactions?
Like Filter support and POST queries, GML comprehension and emission,
all these non-Simple things. The question is not "why should it be
WFS-T" but "why shouldn't it also be this other, kind of WFS-like thing"
As I said before, I think you need POST for Transactions, but I think
this is in line with how others are doing it. I think you could
successfully drop much of the rest, have it be about updating and
inserting single features. And you could theoretically even combine
insert and update to be the same thing (and you'd just version it).
what we're doing to help make it more accessible. I'm definitely open
to a REST API that works against the same backend, if that's what's
needed for 'easy'. Right now we're just extending WFS-T, since there
are clients that implement it already, as opposed to something we just
invent, which may not.
So WFS Simple can be seen just as a more RESTful, geowebbish WFS.
So perhaps i should be having this argument with their discuss list,
and not with you, about Simple implementation of transactions, and use
of the interface for versioning that you are describing, because
transactions without versions are ... like roses without thorns ...
just spammable with worms ... er perhaps i'll try this again in the
morning :) There will only be clients if there are services, and either
way this is partially going to be something you 'just invent'...
Yeah, the big thing you really need is a default encoding. I think it's
ok if you don't have it for WFS reading, but if you're having clients
update the server you really should pick one. Hopefully that's self
describing, flat and simple. GML Level -1
http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal
Nod, i was looking earlier, the extensions are clearly documented but
what would be really helpful would be sample query strings
showing them being used in a request...
Yeah, I realized that when I posted it, it's aimed at WFS people. We'll
work on it.
Andrea, we should probably put implementation and protocol stuff on
separate pages...
We're trying making it as easy as possible. But if you have feedback to
help us on making it even easier, we're all ears, for sure.
No, i'm just kibitzing rather than really offering useful suggestions.
Perhaps WFS
Simple first needs to define what a simple transaction is, make a better
interface than the current WFS, and then we can build versioning on top
of that? Though I have maintained that the Transaction portion of the
spec is actually quite nice - maybe 'Simple' could just make it so it
doesn't stress about namespace and gml validation and all...
This makes a lot of sense... if enough people can consider it in-remit
for Simple... :)
Yeah, let me know if you guys want to go for it, I'm happy to help out
with developing that protocol. Heck, if we do it well and fast we might
implement that first (I do believe for GeoServer we should do both
simple and advanced ways for transactions - half because we already have
clients for the more advanced stuff).
Thanks for sounding in Jo. It may make sense to wait for the read only
simple stuff to settle down first, and to have us prototype with our
WFS-T way, but it's good to at least think about it a bit now.
best regards,
Chris
cheers,
jo
-------------------------------------------------------------------------
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
_______________________________________________
Geoserver-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,456b8c6b314401219810056!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
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
