[mapguide-internals] Viewer HTTP API

[Haris Kurtagic]

Hi,

I would like to share some of my thoughts and experience on this topic.

I think GeoREST could be great addition to MapGuide. We have lot of
success in a projects with it. It is most beneficial when you want to
publish your spatial data to Web (to enable things like Google search
over data)
and basically to link your data into other web applications. For
example to create rich dynamic KMLs which you can use in apps like
Google Earth.
Even if it allows (and we made sample for it) how to use it as JS
viewer ( with new OpenLayers layer) we don't use GeoREST for rich Map
viewer ( in a sense we use them now in MapGuide)

For few years now I have experimented with rich viewer based on HTTP
API and javascript, Flex or Silverlight.
I developed what you called "super agent". It included all current
HTTP API plus additional "RESTful" HTTP API for layers management,
selection, feature editing etc...
I then used JS (and Ext when it was LGPL) to develop rich viewer which
had at least same functionality as current MG viewer.
But except benefit that it was pure HTTP API it didn't bring that much of value.

Anyhow I learned that having good HTTP API is way to go but still it
doesn't mean that it needs to be "RESTful" at all.
I am trying to point out two things:
1. It is great to have RESTful GIS service to be able to connect your
GIS to other services. Right now it seems best protocol for that could
be Atom Publishing Protocol.
    It would make sense to create such protocol to be compatible with
specs like GData and OData. That is way where GeoREST is heading.

2. Fast, optimized and friendly HTTP API could be way to go for reach
Map viewer. Such HTTP API doesn't need to bother with being "REST
compliant" just fast.
    Regarding rich viewer I am leaning toward JS/HTML5 viewer although
Silverlight ( mostly because of .NET developers ) also sounds like
good candidate.

There is lot to talk about this topic but I think I made email lengthy
enough. I apologize for length of it ( I tried to make it short ).

Haris

On Thu, Jun 3, 2010 at 7:01 PM, Trevor Wekel
<trevor_wekel at otxsystems.com> wrote:
> Hi everyone,
>
> At the January PSC meeting, we discussed viewer strategy and the future direction of the HTTP API.  From the meeting, the following general directions were discussed:
>
> * Include GeoREST in MapGuide
> * Move to a pure HTML/Javascript client framework (drop PHP/.Net/Java code from both viewers and implement in mapagent)
> * Make the HTTP API more REST compliant
>
> To facilitate further discussion, I documented the existing HTTP APIs for the Rendering Service http://trac.osgeo.org/mapguide/wiki/HttpApi/RenderingService.
>
> I also took a quick look at the existing PHP code for the Fusion and Ajax viewers.  Fusion has approximately 8000 lines of PHP code and the Ajax viewer has approximately 4000 lines of code.  There is likely some duplication of functionality between the viewers but this is still a lot of code to port to the mapagent.
>
> In addition, we should probably look at some form of pluggable architecture for the mapagent to make it easier to glue in new functionality.  Combining the existing mapagent functionality with GeoREST into a "super agent" might be a good place to start.
>
> Where do we go from here?
>
> Regards,
> Trevor
>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>