Hey Paul and all.
Sorry I missed the irc meeting today, but thought I'd lend a few
thoughts on the topic of versioning in pl/pgsql.
What you say makes sense, and I think it would be great if these ideas
made it in to PostGIS core as pl/pgsql. But this round is really more
prototyping what versioning in WFS would look like. Since Andrea's a
Java and GeoTools guy we're going for a pure java implementation. If
Blasby were still aboard it's more likely there'd be stuff at the
PostGIS level, since he'd have no learning curve for it.
In the longer run, I think we do very much hope that PostGIS will take
some of the concepts we're playing with and implement them at the
database level. We hope to have versioning across datastores, able to
take advantage of the native versioning that the db provides. But what
we're working on now hopefully will be the default implementation for
dbs that don't have native versioning (PostGIS, MySQL, H2, MsSql?,
ect.). But this process should help us figure out what a nice api
should look like, and then hopefully we can push functionality back,
just like we do with spatial operations currently (shapefiles process in
JTS, postgis with its own backend).
So I do agree it would be a huge win to have this functionality in
PostGIS, and we'll do our best to make it compatible with eventually
doing that, and indeed hopefully our designs and needs here will
influence it. If you have someone who has experience implementing in
pl/pgsql who's able to review our current designs and give feedback on
whether it'd be possible/easy to do natively, that'd be great. And if
there's someone available to work on the implementation we'd of course
be more than happy to coordinate at the GeoTools level and make the
right calls (even if that's somewhere down the line... indeed perhaps
our prototype may be able to scare up some additional interest - I'm
happy to support the statement that the 'right' way to do this is
natively in PostGIS, since it is, it's just not what we're going for at
the moment).
best regards,
Chris
<pramsey_> aaime...
<aaime> Yup
<pramsey_> Since you are planning on doing a "postgis-only" datastore
anyways...
<pramsey_> might I suggest that you do the project as a combined
postgis/geotools project? that is...
<pramsey_> Write much of the logic in pl/pgsql and have the datastore
call that logic.
<aaime> I'd really prefer not to
<pramsey_> In that way, your implementation could be shared by
multiple apps... basically, avoid the ArcSDE mistake of having the
intelligence in the middleware.
Which requires that in order to use the capability of your DATABSE, you
also need the middleware.
<jgarnett> brb
|<-- jgarnett has left freenode ("Chatzilla 0.9.77 [Firefox
2.0/2006101023]")
<aaime> I'm shooting at postgis because it's the best supported
datastore
but I want the same on other jdbc datastores
in particular in an embedded datastore that we're thinking about for
geoserver
and that could be based on h2 database
I've never did anything database dependent in my whole life
so it's a hard sell for me
I only see downsides given my experience
<pramsey_> Right, instead you're doing something language/library
dependent.
-->| jgarnett ([EMAIL PROTECTED]) has joined #geotools
<pramsey_> Which, for people who HAVE DATA, in the database, is
frustrating.
<aaime> (I've been writing apps that needed to jump on top of
different database depending on the customer for the last 6 years...)
<acuster> aaime go for it, seems like you have a great plan and we
can rewrite it again a few times later when we understand all the issues
better
the best being an enemy of the good
<pramsey_> The reason why qgis/udig/cadcorp/fme/fdo can interoperate
with postgis data is because they have a shared understanding of what
the data in the database is.
<aaime> Thinking about it Paul, but I have very strong preconceptions
against database dependent stuff
<pramsey_> If you pull database logic up a level, you are basically
creating a new database postgis/geotools, which only a subset of
software can use.
That's the core argument. It's what makes ArcSDE good for ESRI
programmers, but bad for ESRI users.
End of rant, I'll shut up now :)
<aaime> I just faint at the idea of re-implementing everything ontop
of another db
which I know I will have to do anyways for at least a couple of dbs
--
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
