[mapguide-internals] Future Development Options for Web Server Extensions and new High Performance Viewer

Zac Spitzer zac.spitzer at gmail.com
Mon Dec 28 20:39:12 EST 2009 

2009/12/29 Walt Welton-Lair <walt.welton-lair at autodesk.com>:
>> Why is it that there has to be server side code just to toggle layer visibility?
>
> If I have two layers with labels, when I toggle off one of the layers it can affect the placement of labels for the other layer.  So does the label placement logic get moved out of the server?

I think the idea was much simpler in scope, as in being able to toggle layers
in a runtime map via a http call


>
> ________________________________________
> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [ks at geograf.dk]
> Sent: Monday, December 28, 2009 3:37 AM
> To: mapguide-internals at lists.osgeo.org
> Subject: Re: [mapguide-internals] Future Development Options for Web Server     Extensions and new High Performance Viewer
>
> I agree with Zac (and Traian): just fix the HTTP API for AJAX!
> Why is it that there has to be server side code just to toggle layer
> visibility?
>
> If the HTTP API supports all the options that the Web API has, there is no
> need for the Web API, and no need to keep it in 3 or more versions.
>
> Should a Web API be desired, it can use the same API as the HTTP clients
> use, but just skip the HTTP part, and communicate directly with the
> MapGuide service.
>
> I also agree that OL is the thing to use. If there is a need for a
> client side render,
> just add it as a layer type to OL, that way there is also the
> possibility for a fallback/upgrade
> solution for browsers with certain plugins/capabilities.
> (That is also how OL handles the SVG/VML problem).
>
> If you want offline data, you just need MapGuide to convert the
> LayerDefinition to SLD.
> Once that is ready, OL can render your vector data, no coding needed.
> If you use something like google gears, you can store the GML responses
> from MapGuide
> for offline use.
>
> Regards, Kenneth Skovhede, GEOGRAF A/S
>
> On 27-12-2009 11:50, Haris Kurtagic wrote:
>> I  would like to add few of my thoughts.
>> I have tested few web client platforms, Flash/Flex, Silverlight, HTML5
>> Canvas for something like heavy client work with lot of vectors. There is
>> growing number of OS libraries for drawing stuff in canvas or VML/SVG and I
>> tried few of them. I wasn't pleased with any result I was able to get, it
>> was either performance or memory (or stylization). But, certainly things are
>> going to improve.
>>
>> In our project we then used combination of MG2.1 + GeoREST + OpenLayers, so
>> data is rendered as image and then on smaller zoom's we request vector
>> layers and render as such and allow interaction with the vectors. This is
>> combination of MG server rendering and vector rendering on client side.
>>
>> Recently OS svgweb project came out and it seems to me that SVG could be
>> something to look more into. SVG and HTML5 promising to be good combo.
>>
>> Also,  AutoCAD/MAP is in our projects very important MapGuide client. Not to
>> connect to data directly but trough web/http services and wms/wfs is not
>> enough. We are using FDO provider for GeoREST/MapGuide but much more is
>> needed there and I believe lot of our attention will go in that direction.
>>
>> In the end I don't have answer to myself what would be the right
>> technology/platform for client to focus on. I do know that MG needs to
>> support browsers, mobile solutions but also desktop apps like AutoCAD.
>>
>> I believe there is lot of work on server side which needs to be done to get
>> open/fast/scalable platform which could effectively support such clients.
>> Right now my focus is on the server side of story.
>>
>> Haris
>>
>>
>>
>> On Sun, Dec 27, 2009 at 7:35 AM, Jackie Ng<jumpinjackie at gmail.com>  wrote:
>>
>>
>>> Just another guy with no oar in the water :-)
>>>
>>> I am in favour of whichever solution/technologies that allows the viewer to
>>> operate in a *disconnected/offline* scenario. I believe that this will open
>>> up a whole bunch of scenarios that were previously not possible with
>>> MapGuide in its current form.
>>>
>>> Also I think that we shouldn't stress too much about IE6 support. If they
>>> want to still live in 2001 and not move with the times, they can always
>>> stick with the basic AJAX viewer :-P
>>>
>>> - Jackie
>>>
>>>
>>> Carsten Hess wrote:
>>>
>>>> Jason,
>>>>
>>>> I like that you go back to the use cases. Personally I agree that the
>>>> server load is only a partial problem as hardware is cheap compared to
>>>> software. Don't get me wrong, I think there is plenty that we as an
>>>> overall community could do to make MapGuide more thread-able (have better
>>>> multi-processor and multi-server support). I also believe that some
>>>> rendering on the client is very intriguing as the clients have a lot of
>>>> computing power to share that often lays dormant.
>>>>
>>>> I think the second one use-case you talk (thick client for performance)
>>>>
>>> is
>>>
>>>> significantly more work compared to editing which I am happy to elaborate
>>>> on.
>>>>
>>>> If you just do editing and assume a 100ms turnaround time for
>>>>
>>> web-requests
>>>
>>>> you can let the server do tons of simple operations (i.e. compute line
>>>> patterns, compute snapping points, etc) for the client without recoding
>>>> and loading all this data to the client. This comes to another
>>>>
>>> interesting
>>>
>>>> observation: In a web-environment we have to weigh network load against
>>>> server-load for real benefit.
>>>>
>>>> I think it would be very interesting to compare the data and packaging
>>>> cost of vectors vs. rendered images. I bet we would find that feature
>>>>
>>> wise
>>>
>>>> dense maps, maps with lots of pattern / line styles, or raster layer and
>>>> operations are more expensive to do on the server compared to do it on
>>>> clients. At the same time they would be a lot cheaper on the network load
>>>> if done on the server. I bet you would find the other extremes also to be
>>>> true and find cases where sending the feature data over the wire would be
>>>> more expensive on network and server compared to the rendering. Just
>>>>
>>> think
>>>
>>>> of a complex theming - the data would have to travel much further from
>>>>
>>> the
>>>
>>>> data-tier if you do client side rendering.
>>>>
>>>> So in my opinion a mixed environment holds nirvana - and a lot of work -
>>>> for both use cases! And then there is the stuff Traian hacks together
>>>>
>>> that
>>>
>>>> shows that simple solutions are not only fast but possible now compared
>>>>
>>> to
>>>
>>>> next year - nice work on that canvas based rendering Traian!
>>>>
>>>> I also want to double your last comment. I don't have an oar in that
>>>>
>>> water
>>>
>>>> either. It is just something I have thought about a bit and want to share
>>>> my thoughts on. Feel free to disregard :)
>>>>
>>>> Cheers,
>>>>    Carsten
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
>>>> Birch
>>>> Sent: Saturday, December 26, 2009 3:14 PM
>>>> To: MapGuide Internals Mail List
>>>> Subject: Re: [mapguide-internals] Future Development Options for Web
>>>> Server Extensions and new High Performance Viewer
>>>>
>>>> Carsten,
>>>>
>>>> I see two different use cases. One, for a disconnected editor, where a
>>>> very thick client would be of great use. Two, for a slightly thicker
>>>> client for higher performance. Server load is, I suppose, somewhat of
>>>> a concern, but from my perspective isn't really critical... You can
>>>> always throw more hardware at a task :)
>>>>
>>>> The first of these would require substantial re-implementation of the
>>>> mapguide interfaces ( or a non-direct port where mapguide is combines
>>>> with a bunch of other modules ) and has its own value proposition.
>>>>
>>>> The second of these may be able to provide benefits from some changes
>>>> to the mapagent to output an optimized format for the client. Have a
>>>> look at the GeoREST sample that haris built using KML output to render
>>>> in openlayers. Its not perfect, but its a step in the right direction
>>>> I think. Basically GeoREST is rendering a vector format for
>>>> consumption by the client.
>>>>
>>>> Finding the right balance of what to keep server side and what to
>>>> re-implement on the client may be difficult, but I think we could see
>>>> considerable benefit from looking at each layer.
>>>>
>>>> Note, I like talking about this stuff, but don't have an oar in the
>>>> water on this particular item yet, so take what I say for what its
>>>> worth :)
>>>>
>>>> Jason
>>>>
>>>> Jason
>>>>
>>>> On 2009-12-26, Carsten Hess<carsten.hess at autodesk.com>  wrote:
>>>>
>>>>> Ok, I tend to stay quite on this list but this is something of interest
>>>>> to
>>>>> me. I agree that client side rendering could help one aspect of the
>>>>> "scalability" of the server.
>>>>>
>>>>> So far the discussion has been all platform related but not talked about
>>>>> what the capabilities of such a client would be. Porting some of the
>>>>>
>>> code
>>>
>>>>> and API's would not be trivial to say the least. So I have my doubts
>>>>>
>>> that
>>>
>>>>> a
>>>>> heavy client would have the same "features" as MapGuide does today
>>>>>
>>> unless
>>>
>>>>> you can reuse code.
>>>>>
>>>>> As for platform, Traian quoted I think Stroustroup to me about a week
>>>>> having
>>>>> said "Java is not platform independent - Java is a platform". I totally
>>>>> agree with that whoever said it and I think flash is even more so a
>>>>> platform. Many small devices do support open web technologies like
>>>>>
>>> canvas
>>>
>>>>> and HTML5 but won't support Java or Flash. The most extreme example is
>>>>> the
>>>>> IPhone / Pod platform. Looking forward I believe that these devices will
>>>>> be
>>>>> more important than the intranet /internet / web-browser.
>>>>>
>>>>> Anyways, I think the real influence I would like to have on this
>>>>> discussion
>>>>> is to point out how much functionality there is on the server that would
>>>>> need to move or be given up / replaced.
>>>>>
>>>>> Cheers,
>>>>>    Carsten
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac
>>>>> Spitzer
>>>>> Sent: Thursday, December 24, 2009 7:56 PM
>>>>> To: MapGuide Internals Mail List
>>>>> Subject: Re: [mapguide-internals] Future Development Options for Web
>>>>> Server
>>>>> Extensions and new High Performance Viewer
>>>>>
>>>>> but openlayers is the defacto js api for geo spatial,
>>>>> and there are a lot more javascript developers than flash,
>>>>> plus it would 'just work' with our existing fusion client
>>>>> and also cool things like GeoExt
>>>>>
>>>>>
>>>>>
>>>>> 2009/12/25 Jason Birch<jason at jasonbirch.com>:
>>>>>
>>>>>> It may be more productive to contribute to OpenScales; it's based on
>>>>>> the OL idea, but in flash. It's not especially fast (I think its still
>>>>>> thinking mostly about rasters) but I think with the right contributors
>>>>>> it could be and duplication of effort / NiH sucks :)
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> On 2009-12-24, Zac Spitzer<zac.spitzer at gmail.com>  wrote:
>>>>>>
>>>>>>> I'd propose that what ever gets done, should be based on Openlayers
>>>>>>> as a dynamic layer. That way we can leverage everything else already
>>>>>>> done
>>>>>>> in OL. It also reduces the amount of work required by a factor of like
>>>>>>> 100,
>>>>>>> plus there's a lot more dev's around in OL land
>>>>>>>
>>>>>>> Plugins are rather 1990's, I agree with Jason that flash is a good
>>>>>>> option,
>>>>>>> but it i reckon it should just be a layer renderer which fits into the
>>>>>>> OL framework
>>>>>>> if at all possible....
>>>>>>>
>>>>>>> The possibilities with HTML5 Canvas are pretty cool...
>>>>>>>
>>>>>>> As for browser support, I would suggest, shock horror, we only target
>>>>>>> modern
>>>>>>> browsers, forget IE6 completely, and given the rumours about IE9
>>>>>>> supporting
>>>>>>> real world javascript peformance, perhaps ignore IE7 and even IE8, as
>>>>>>> neither
>>>>>>> supports Canvas
>>>>>>>
>>>>>>> that said, a flash layer for OL would avoid that problem :)
>>>>>>>
>>>>>>> 2009/12/25 Jason Birch<jason at jasonbirch.com>:
>>>>>>>
>>>>>>>> Oh, and I'm running on about 3 hours sleep in last 48, so sorry if
>>>>>>>> that
>>>>>>>> was
>>>>>>>> overly cranky :)
>>>>>>>>
>>>>>>>> 2009/12/24 Jason Birch
>>>>>>>>
>>>>>>>>
>>>>>>>>> I can't believe that custom ActiveX or Java are seriously being
>>>>>>>>> considered.
>>>>>>>>>   Is there no organisational memory of how much of a pain in the ass
>>>>>>>>> it
>>>>>>>>> was
>>>>>>>>> for customers to maintain multiple implementations of MapGuide just
>>>>>>>>> to
>>>>>>>>> make
>>>>>>>>> sure that everyone could use it?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> mapguide-internals mailing list
>>>>>>>> mapguide-internals at lists.osgeo.org
>>>>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Zac Spitzer
>>>>>>> Solution Architect / Director
>>>>>>> Ennoble Consultancy Australia
>>>>>>> http://www.ennoble.com.au
>>>>>>> http://zacster.blogspot.com
>>>>>>> +61 405 847 168
>>>>>>> _______________________________________________
>>>>>>> mapguide-internals mailing list
>>>>>>> mapguide-internals at lists.osgeo.org
>>>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> mapguide-internals mailing list
>>>>>> mapguide-internals at lists.osgeo.org
>>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Zac Spitzer
>>>>> Solution Architect / Director
>>>>> Ennoble Consultancy Australia
>>>>> http://www.ennoble.com.au
>>>>> http://zacster.blogspot.com
>>>>> +61 405 847 168
>>>>> _______________________________________________
>>>>> mapguide-internals mailing list
>>>>> mapguide-internals at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>> _______________________________________________
>>>>> mapguide-internals mailing list
>>>>> mapguide-internals at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>
>>>>>
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>> _______________________________________________
>>>> mapguide-internals mailing list
>>>> mapguide-internals at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>
>>>>
>>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/Future-Development-Options-for-Web-Server-Extensions-and-new-High-Performance-Viewer-tp4208470p4219854.html
>>> Sent from the MapGuide Internals mailing list archive at Nabble.com.
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>



-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168

More information about the mapguide-internals mailing list