Hey- Christopher Schmidt wrote: > On Mon, Apr 14, 2008 at 10:02:13PM -0400, Christopher Schmidt wrote: >> On Mon, Apr 14, 2008 at 05:46:47PM -0600, Tim Schaub wrote: >>> Hey- >>> >>> Some may have already seen the proposal for new vector layer behavior. >>> http://trac.openlayers.org/wiki/Proposal/VectorBehavior >>> >>> This week, I'll be working on implementing a bit of this new design. >>> I'm focussed on an AtomPub protocol, an Atom format, and a somewhat >>> smartish BBOX strategy. >> Thanks for the email letting us know what's up. >> >> Out of curiosity: some Protocols seem likely to be 'trapped' within a >> single Format. I'm assuming that you don't see any problem with that, so >> long as it is sufficiently documented. I'm asking only because the >> majority of protocols seem to clearly be in a position where they'll be >> able to cope with many formats -- WFS read support, AtomPub support, >> etc. -- while a minority -- ESRI-REST, WFS-T/write, etc. -- are tied to >> a specific Format. Does this make sense? Is a format-specific protocol >> still a protocol? (I think yes.) > > Alright, based on my assumption, I've gone ahead and implemented Google > Gears and HTML5 Local Storage support. > http://crschmidt.net/mapping/localdb/ . Patch is at > http://crschmidt.net/~crschmidt/localdb.patch ; it's in SVK. When you > guys are done on your push, let me know, and we can talk about the best > way to integrate. >
Looks nice. I really want to make sure we get this right before being stuck with any one design. The more implementations the better - as long as nobody is promising *anybody* about things being set in stone. Perhaps SQL is a better protocol name (just a bit closer to "protocol" than HTML5). Tim > This demo uses the local database in your browser to store features. > read(), create(), update(), delete() are committed: my assumption at > this point is that commit() will eventually be implemented on the base > Protocol() class, so I didn't bother to implement that method. > > I would not recommend anyone using this code for long term anything at > the moment, since at the very least there is an obvious use case for a > four-tuple based 'bbox' query, but it was a way to get a quick proof of > concept up in a night. > > Regards, _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
