Call for comments -RFC 39

[Steve Lime]

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
>>
> 
> 


-- 
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------