[OpenLayers-Dev] vector behavior

[Tim Schaub]

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,