[OpenLayers-Users] GeoRSS and Custom Icons

[Eric Lemoine]

Current HTTP Protocol does CRUD through HTTP POST, GET, PUT, DELETE.
It should be generic enough for implementing Protocol.FeatureServer
and Protocol.OSM based upon it. So if we keep it as-is i tend to think
we should rename it REST. However i like your idea of having a simple
read-only, HTTP GET-based Protocol that other network Protocols will
use internally. Thanks. Eric

2008/6/29, Christopher Schmidt <crschmidt at metacarta.com>:
> On Sun, Jun 29, 2008 at 11:34:23AM +0200, Eric Lemoine wrote:
>> Hi. Regarding Protocol.HTTP maybe the naming isn't really appropriate
>> since any OL network protocol is HTTP-based.
>
> The Google Gears protocol is HTTP based? :)
>
>> Since Protocol.HTTP uses
>> GET, POST, PUT, DELETE, Protocol.REST might be a better name.
>
> That depends what we put in the HTTP protocol. My assumption was that
> something like OSM and something like FeatureServer could both be based
> on subclasses of the HTTP Protocol -- that the HTTP Protocol wouldn't
> actually embed any write information, only reading from bounding boxes.
>
> If the plan is to have the HTTP Protocol do more than that, then yes,
> perhaps REST makes sense, but I think there is still a class of
> HTTP-centric, non-SimpleFeatures REST that could be usefully subclassed
> from a smaller protocol.
>
> -- Chris
>
>>
>> 2008/6/25, Christopher Schmidt <crschmidt at metacarta.com>:
>> > On Wed, Jun 25, 2008 at 03:53:33PM +0200, Eric Lemoine wrote:
>> >> On Wed, Jun 25, 2008 at 3:09 PM, Christopher Schmidt
>> >> <crschmidt at metacarta.com> wrote:
>> >> > On Wed, Jun 25, 2008 at 01:54:42PM +0200, Eric Lemoine wrote:
>> >> >> Although i find it weird to use a GML layer with a format different
>> >> >> than GML i agree that it's good to avoid code at the application
>> >> >> level. Thanks Andreas. Eric
>> >> >
>> >> > As Andreas pointed out, this is a flaw in naming. This is simply for
>> >> > 'historical reasons' -- It was named that way early on, before I
>> >> > really
>> >> > knew what I was doing. (It was named, for example, before we had
>> >> > formats, back when it really *was* about GML.)
>> >> >
>> >> > The GML and WFS layers can essentially be thought of two different
>> >> > strategies: GML is a Layer which uses a "Fixed" strategy, and WFS is
>> >> > a
>> >> > Layer which uses a "BBOX" strategy.
>> >> >
>> >> > Both of them are tied to the HTTP Protocol.
>> >>
>> >> The WFS layer is tied to the "WFS" protocol.
>> >
>> > More so than the HTTP protocol, I'll admit; but the entire reason for
>> > the vector behavior work is just that the protocol stuff really isn't
>> > well encapsulated, so we'll just put it this way: "The WFS layer is a
>> > fscking mess" :)
>> >
>> >> > It's unfortunate that they're named this way, but that's one of the
>> >> > things that the vector behavior work is changing: once we've
>> >> > refactored
>> >> > things, we can start creating layers that actually make sense for
>> >> > their
>> >> > names :)
>> >>
>> >> Ok, but what will we do with the WFS and GML layers? Will we keep them
>> >> with the same names and behaviors to maintain backward compatibility?
>> >
>> > I don't know exactly what we'll do: if we can change the underlying
>> > implementation of these to just be simple wrappers around a vector layer
>> > without changing API-supported behavior, that would be preferable:
>> > otherwise, we may have to maintain the existing code. For example, the
>> > WFS layer has support to render with Markers, something that the vector
>> > behavior changes won't give us, so we can't really just dump the
>> > Layer.WFS code that does that and depend on the vector behavior instead.
>> >
>> > Regards,
>> > --
>> > Christopher Schmidt
>> > MetaCarta
>> >
>
> --
> Christopher Schmidt
> MetaCarta
>