[mapguide-internals] MapGuide Comments

[Haris Kurtagic]

Keeping additional data in session sounds ok.
Keeping Map state is something I am not sure off.
To keep state in two places client and server doesn't sound right.
Also, there could be use case where several different views (Map State)
on same Map/Sesssion data would be implemented.
I am trying to understand implication's of Map/Session design and thank
you for your help.

Haris


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Robert
Bray
Sent: Thursday, September 13, 2007 5:32 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide Comments

Right and it is not just buffers. Any kind of spatial analysis typically

leads to temporary data. Redline/markup and/or live data edit would also

typically be kept in a session until the user was ready to save or 
commit their changes to a permanent data store.

Also keeping map state in a session means smaller packets can be sent 
from client to server. E.g. the server only needs to know the delta in 
layer state, not the visibility of all layers in order to render a map. 
On the web today this is not all that important, but if we wanted to 
support wireless/mobile clients in the future then this is pretty 
attractive.

Bob

Haris Kurtagic wrote:
> Yes, I was also thinking about returning all images at once, I read
> about this Image strips (not familiar with those) but sounds like way
to
> go.
> 
> Buffers, I forgot about those.
> 
> Thank you,
> Haris
> 
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
Robert
> Bray
> Sent: Wednesday, September 12, 2007 12:53 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] MapGuide Comments
> 
> Harris,
> 
> I could not agree more on your first point. In fact I would love to 
> optimize that to send some kind of legend image strip in one operation

> to avoid all the round-trips.
> 
> As for this comment:
> 
>  >>I am setting Map view parameters and request for image in one
> request,
>  >>good or bad ?
> 
> I think your approach is good. In fact that is the way the DWF Viewer 
> works as a client.
> 
> Sessions are necessary for other stuff, like temporary layers, data, 
> etc. A buffer for example creates a temporary SDF and layer. You can 
> then use that SDF for further geo-processing, etc.
> 
> Thanks,
> Bob
> 
> Haris Kurtagic wrote:
>> I am working on MapGuide RESTful service and digging deep into
> MapGuide.
>> I have a lot of good words on what Autodesk guys did, good job.
>>
>>  
>>
>> I would like to comment on things that I don't like or understand and
>> hopefully to hear other opinions.
>>
>>  
>>
>> 1.       Legend Image Icon creation is very paintfull and error
prone.
>>
>> To request for Icon you need to send few parameters scale, theme rule
>> index, geometry type,...
>>
>> What is happing is that viewer's are deciding on geometry type not on
>> feature source geometry type but reading from XML ( PointStyle,
>> LineStyle, Polygon, Combo ) by string tag.
>>
>> Then they will convert it into geometry type (and wrongly for
> ComboStyle
>> - will go to Multi Point). Server rendering is expecting real
geometry
>> type to find appropriate feature style (getting feature source and
>> correct geometry type would be even more overhead).
>>
>>  
>>
>> I see several problems: here viewers have hard-coded schema elements,
>> not correctly setting required geometry type, exception's on wrong
>> scale, exception if data on server is changed.
>>
>> One of problems is if server can't figure out rule for example
setting
>> incorrect scale will crash web-tier badly ( null-pointer access).
>>
>> This can be repeated with Sheboygan example and if you send request
> for
>> District legend icon with scale=0, it will not find it and will
return
>> null image and agent crashes ( HttpGetLegendImage needs if in 134
line
>> or throw exception in server).
>>
>>  
>>
>> What I think would be right is to have Id for rule so you would
simple
>> request for image by id instead of ( scale, geometry type, rule index
> ).
>> I wrote a lot about not so "important" thing but it took us a lot of
>> time :)
>>
>>  
>>
>> 2. Session - what are reasons for having session's ?
>>
>> To store Map runtime parameters ( center, scale layers show/hide,
>> selection). Viewers are keeping this parameters of map and basically
>> doing two requests one to set these properties to runtime map and
>> another one to request image.
>>
>> To store user credentials - session as token, that I think is  OK.
>>
>> I am setting Map view parameters and request for image in one
request,
>> good or bad ?
>>
>>  
>>
>> Thanks ,
>>
>> Haris
>>
>>  
>>
>>  
>>
>> _______________________________________________
>> 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