Call for comments -RFC 39

Fri Nov 30 16:57:48 EST 2007

I'm usually for keeping things simple... I just not convinced that the 
CLASSGROUP proposal will necessarily result in a simpler codebase at the 
end of the day. I'm also worried about potential performance hits and 
code complexity.

All that extra mechanic to deal with caching of the string comparisons 
on the class group names, the addition of an extra (hidden) member 
inside the class object to cache the result, and the modifications to 
all places that deal with classes to skip/ignore classes that don't 
match the current classgroup will definitely add code complexity.

OTOH, with a higher level object such as THEME, of course we need to 
update all places that access classes to make them aware of the theme 
object, but once that's done, the resulting code should be cleaner (or I 
would hope so anyway).

I don't even think my THEME suggestion could be called a "perfect" 
solution either... the perfect solution would be as you suggested, to 
rethink the way we approach styling, the use of style files, etc... and 
that would take quite a bit of time and thinking.

And in that context we could conclude that implementing THEMEs without 
thinking about the long term direction of styling and style tables may 
not be a good idea either since we're not sure if THEME is what we'll be 
using at that time... which takes us back to the "better than nothing" 
CLASSGROUP solution.

I guess I'm not sure any more...

Daniel

Steve Lime wrote:
> Then I guess we're facing a "better than nothing" decision. Which is ok by me
> (I'm often function over form) with the option later of changing if warranted. 
> 
> Steve
> 
>>>> Yewondwossen Assefa <yassefa at dmsolutions.ca> 11/29/07 1:23 PM >>>
> 
>   Thanks for the comments.
> 
>   You have mentioned several aspects of changes that need to occur to be 
> able to introduce a level above classes and also keep full backward 
> compatibly. I have not assessed all the changes needed and beside those 
> you mentioned, quickly going trough mapserver.h and doing a grep to see 
> where layer->classs/numclasses gives another aspect of the changes needed.
> 
>   I have no doubt that the theme concept is a better architecture. But I 
> find myself thinking that at the end of the day, the user would get the 
> same functionality either ways, (of course one being more intuitive), 
> there would be no risk of backward compatibility issues or major 
> disruptiveness in the MapServer architecture and I think this has also 
> merits and should be weighted against the "perfect" architecture.
>   I also mentioned in earlier e-mail that there is nothing preventing us 
> from deprecating one way of doing this if/when the theme concept is 
> introduced. I put "if" because the idea of a higher level object on top 
> of the class object is absolutely not new and was briefly discussed when 
> I initially worked on the SLD support and realized the need of it, and 
> that was in 2003.  For some reason (possibly funding/time/demand ), It 
> was never pursued. This is not an indication that it will not be 
> implemented soon, but just to note that it could also take several years 
> before something is done.
> 
> I am not sure at this time if I will have time/funding to do changes 
> needed for the theme. I also think that this feels more like something 
> to be done for a major release with all other considerations such as 
> reviewing the way we approach styling, the use of a styling file, etc ...
> 
>   Best Regards,
> 
> Steve Lime wrote:
>> My Appologies, I haven't been watching mapserver-dev closely for the last couple
>> of days. I gotta kill the auto filing for mapserver-dev and mapserver-users...
>>
>> After reading Daniel's most recent comments I guess I kinda like the theme idea
>> too. That said, it's a good more disruptive than the group idea, at least for mapfile
>> parsing and mapscript access. I think the theme idea would be easier to implement
>> for the drawing and query code, just reference the right theme and proceed like
>> now. Which to pick...
>>
>> For mapfile parsing we could handle themes the way we handled moving things
>> like COLORs from a classObj to a styleObj. The parser still recognizes COLOR at
>> the class level but actually stuffs that value into style[0]. So, if a CLASS were
>> encountered at the layerObj level you'd in essence be populating theme[0] in
>> the layerObj. So, you could maintain mapfile backwards compatibility. There would
>> always be at least one theme.
>>
>> The bigger problem would be MapScript I think. I wonder if all the layer methods
>> for accessing classes would fall apart. Perhaps not if the theme index were optional
>> and defaulted to 0 so code like $layer->getClass(0); could possibly still work.
>>
>> All the copying code etc... would need to be fixed to deal with one more level of
>> hierarchy. 
>>
>> So, the theme idea touches a lot more code but feels like less of a kludge. Is there
>> enough funding to pursue that extra work? 
>>
>> Also, depending on how backwards compatibility with mapfiles (I'm sure that can be 
>> made to work) and mapscript is an issue I'm not sure this feels like a 5.2 modification, 
>> more like a 6.0. If compatible, 5.2, if compatibility is broken, then 6.0.
>>
>> Steve
>>
> 
>>>>> Yewondwossen Assefa <yassefa at dmsolutions.ca> 11/26/07 4:40 PM >>>
>> Steve,
>>
>>   If you have a chance, can you comment on this. I would like to have 
>> your inputs before either going forward with a vote or retract the RFC.
>>
>> Thanks
>>
>> Steve Lime wrote:
>>> I need to take a look at this and compare notes with the discussion we had a bit ago. I'll
>>> try to do that in the next few days.
>>>
>>> Steve
>>>
>>>>>> On 11/20/2007 at 2:53 PM, in message <4743495D.6000903 at dmsolutions.ca>,
>>> Yewondwossen Assefa <yassefa at DMSOLUTIONS.CA> wrote:
>>>> Frank, all
>>>>
>>>>> I believe I had misunderstood.  So the classgroup declaration just defines
>>>>> which style group will be used by default if it is not overridden using
>>>>> STYLE= or another override mechanism?  This makes sense, but perhaps need
>>>>> to be made as clear as possible in eventual documentation.
>>>>>
>>>>   I have added a note in the RFC to clarify a bit more the use of 
>>>> CLASSGROUP.
>>>>
>>>>
>>>> I would like to push for more comments or a vote on this.
>>>>
>>>> Thanks
>>
> 
> 

-- 
Daniel Morissette
http://www.mapgears.com/