RFC60 - Memory Management & Object LifeCycle Issues between Mdf Parser and runtime Maps

[UV wild]

The style guide talks about auto_ptr and I have seen the Ptr<> template
class being used in the code.

But so far I am using a std::list container for the collection of colors
in the VectorLayerDefinition (making full use like sort90 and unique())
when creating the final Palette for the Image renderer.
Using the Ptr template classes on an STL container does not compile!

This now throws up some questions regarding the lifecycle of objectts

1) the MdfModel seems to have a limited lifespan.... however the
VectorLayerDefinition is the source of the color table.
    if I take the MdfStrings from the VLD how long do the live? Can I
keep some references or do I need to copy the Strings or Adopt them?
    Is the MdfModel shared between the runtime Maps or between sessions?
Or is it always deserialized/serialized from a stream as a caching method?

2) Is there a possibility that the same runtime MgMap is being used for
different baseMapGroups?

Can someone please shed some light on those lifecycle issues?
I try to investigate with the debugger but its quite tedious with so
many threads....

I think this is essential to prevent memory leaks.....

Cheers
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Traian Stanev]

You should not use Ptr<> for STL objects. It's specifically used for refcounted MapGuide API objects, which implement a specific interface (MgDisposable).

1) Children of the LayerDefinition will die if their parent dies. If you need them for longer, copy them, instead of pointing to them. Alternatively, keep the LayerDefinition alive until you are done -- this is what the rendering code does, for performance reasons.

2) I don't know what you mean. You mean the same runtime MgMap object instance?

Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: Friday, March 20, 2009 12:15 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 - Memory Management & Object LifeCycle Issues between Mdf Parser and runtime Maps

The style guide talks about auto_ptr and I have seen the Ptr<> template
class being used in the code.

But so far I am using a std::list container for the collection of colors
in the VectorLayerDefinition (making full use like sort90 and unique())
when creating the final Palette for the Image renderer.
Using the Ptr template classes on an STL container does not compile!

This now throws up some questions regarding the lifecycle of objectts

1) the MdfModel seems to have a limited lifespan.... however the
VectorLayerDefinition is the source of the color table.
    if I take the MdfStrings from the VLD how long do the live? Can I
keep some references or do I need to copy the Strings or Adopt them?
    Is the MdfModel shared between the runtime Maps or between sessions?
Or is it always deserialized/serialized from a stream as a caching method?

2) Is there a possibility that the same runtime MgMap is being used for
different baseMapGroups?

Can someone please shed some light on those lifecycle issues?
I try to investigate with the debugger but its quite tedious with so
many threads....

I think this is essential to prevent memory leaks.....

Cheers
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[UV-2]

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Trevor Wekel]

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Tom Fukushima]

Anyone, what's the next step here?

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: Friday, September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Tom Fukushima]

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Trevor Wekel]

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".


Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?


Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Martin Morrison]

Here I go sticking my nose in where it probably doesn't belong again...

In my mind if we add RFC60 and Fusion fixes/updated version we are going to need to start completely over on the testing at the beta stage.  (forget release candidate status).  I'm not knocking any of the fixes/changes that are in these, I'm just saying we can't keep adding new features without an end in sight.  (yes, I consider the Fusion fixes a new feature)  Do a release 2.11 in a month or so and put these fixes in.  Just don't keep holding a final 2.1 release pending more bigger and better things.

I will go wipe my nose now...

Martin


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 1:49 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".


Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?


Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Tom Fukushima]

I've been creating sandboxes that are branches of the full source.  Not sure what the value of an empty sandbox would be to UV.  Anyway, he can delete it and recreate another one.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 11:49 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".


Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?


Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Trevor Wekel]

Hi Martin,

I have not personally taken a run at the latest code base so I do not know how good Fusion is right now.  But I personally believe a usable, working Fusion is key to the success of this release.  In other words, a think it is a "must have".

The RFC 60 work would probably fall into the "nice to have" category but switching to PNG8 with an appropriate palette can reduce network bandwidth by a factor of 3x or more when serving tiles.  The current bandwidth usage for PNG32 easily makes it a non-starter for internet apps.  PNG32 tiles are beautiful but they take a really long time to download.  It will make your ISP happy but that's about it.

without palette support, PNG8 rendering is simply problematic due to color skew.  A feature that is supposed to be red can turn out purple if red gets overlooked during quantization.

I totally agree though.  2.1 is WAYYY overdue.  But I consider, and I suspect the rest of the PSC will too, a new Fusion drop and RFC 60 to be new Features.  According to the published release process that we are trying to follow, neither of these can be put into 2.1.1.  If we follow the process, they would have to wait until 2.2.

If additional defects related to a new drop of Fusion and RFC 60 are found in 2.1, those can be fixed in 2.1.1 because they are simply defects on a released feature.
 

Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Morrison
Sent: September 18, 2009 12:07 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Here I go sticking my nose in where it probably doesn't belong again...

In my mind if we add RFC60 and Fusion fixes/updated version we are going to need to start completely over on the testing at the beta stage.  (forget release candidate status).  I'm not knocking any of the fixes/changes that are in these, I'm just saying we can't keep adding new features without an end in sight.  (yes, I consider the Fusion fixes a new feature)  Do a release 2.11 in a month or so and put these fixes in.  Just don't keep holding a final 2.1 release pending more bigger and better things.

I will go wipe my nose now...

Martin


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 1:49 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".


Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?


Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Trevor Wekel]

Hi Tom,

Ok.  I can certainly create a copy of either 2.1 or trunk under rfc60.  However, as the PSC I think we need to decide if this feature is going into 2.1.  Otherwise, we will have to blow the sandbox away again.  Alternatively, I could create an rfc60/trunk and an rfc60/2.1.  That might be a better solution since the two code bases are probably very different at this point.

In any case, a clean copy of 2.1 or trunk should be the starting point for sandbox/rfc60.  I personally want to see ALL the diffs to help evaluate risk and impact.

Thanks,
Trevor

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 12:22 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

I've been creating sandboxes that are branches of the full source.  Not sure what the value of an empty sandbox would be to UV.  Anyway, he can delete it and recreate another one.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 11:49 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".


Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?


Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Martin Morrison]

Trevor,

I'm going to correct your misspelling...

"2.1 is WWWWWWAAAAAAAAAAAAAAAYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY overdue."  

<G>

Of course, somebody will probably chime in that I didn't add enough characters...

Just keep in mind there are some pretty decent fixes for the AJAX viewer that are being held up.  I say put the release out and let whoever is going to use Fusion patch it until the next release is out.  If I'm correct there isn't an absolute date that they are saying Fusion is guaranteed ready by is there?  

As far as the PNG32 performance goes, if you are after pure performance use JPG, yes it doesn't look as good.  Besides as far as 2.11 goes, if we are following the rules and schedule precisely, nothing else would be added at this point.

Yes, I refuse to use a beta or release candidate on a production box as a matter of policy/liability.

Thanks,
Martin



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 2:43 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Hi Martin,

I have not personally taken a run at the latest code base so I do not know how good Fusion is right now.  But I personally believe a usable, working Fusion is key to the success of this release.  In other words, a think it is a "must have".

The RFC 60 work would probably fall into the "nice to have" category but switching to PNG8 with an appropriate palette can reduce network bandwidth by a factor of 3x or more when serving tiles.  The current bandwidth usage for PNG32 easily makes it a non-starter for internet apps.  PNG32 tiles are beautiful but they take a really long time to download.  It will make your ISP happy but that's about it.

without palette support, PNG8 rendering is simply problematic due to color skew.  A feature that is supposed to be red can turn out purple if red gets overlooked during quantization.

I totally agree though.  2.1 is WAYYY overdue.  But I consider, and I suspect the rest of the PSC will too, a new Fusion drop and RFC 60 to be new Features.  According to the published release process that we are trying to follow, neither of these can be put into 2.1.1.  If we follow the process, they would have to wait until 2.2.

If additional defects related to a new drop of Fusion and RFC 60 are found in 2.1, those can be fixed in 2.1.1 because they are simply defects on a released feature.
 

Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Morrison
Sent: September 18, 2009 12:07 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Here I go sticking my nose in where it probably doesn't belong again...

In my mind if we add RFC60 and Fusion fixes/updated version we are going to need to start completely over on the testing at the beta stage.  (forget release candidate status).  I'm not knocking any of the fixes/changes that are in these, I'm just saying we can't keep adding new features without an end in sight.  (yes, I consider the Fusion fixes a new feature)  Do a release 2.11 in a month or so and put these fixes in.  Just don't keep holding a final 2.1 release pending more bigger and better things.

I will go wipe my nose now...

Martin


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 1:49 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".


Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?


Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Trevor Wekel]

I agree.  If you are using AJAX for your site, the current code base is probably ready to rock and roll.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Morrison
Sent: September 18, 2009 1:03 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Trevor,

I'm going to correct your misspelling...

"2.1 is WWWWWWAAAAAAAAAAAAAAAYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY overdue."  

<G>

Of course, somebody will probably chime in that I didn't add enough characters...

Just keep in mind there are some pretty decent fixes for the AJAX viewer that are being held up.  I say put the release out and let whoever is going to use Fusion patch it until the next release is out.  If I'm correct there isn't an absolute date that they are saying Fusion is guaranteed ready by is there?  

As far as the PNG32 performance goes, if you are after pure performance use JPG, yes it doesn't look as good.  Besides as far as 2.11 goes, if we are following the rules and schedule precisely, nothing else would be added at this point.

Yes, I refuse to use a beta or release candidate on a production box as a matter of policy/liability.

Thanks,
Martin



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 2:43 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Hi Martin,

I have not personally taken a run at the latest code base so I do not know how good Fusion is right now.  But I personally believe a usable, working Fusion is key to the success of this release.  In other words, a think it is a "must have".

The RFC 60 work would probably fall into the "nice to have" category but switching to PNG8 with an appropriate palette can reduce network bandwidth by a factor of 3x or more when serving tiles.  The current bandwidth usage for PNG32 easily makes it a non-starter for internet apps.  PNG32 tiles are beautiful but they take a really long time to download.  It will make your ISP happy but that's about it.

without palette support, PNG8 rendering is simply problematic due to color skew.  A feature that is supposed to be red can turn out purple if red gets overlooked during quantization.

I totally agree though.  2.1 is WAYYY overdue.  But I consider, and I suspect the rest of the PSC will too, a new Fusion drop and RFC 60 to be new Features.  According to the published release process that we are trying to follow, neither of these can be put into 2.1.1.  If we follow the process, they would have to wait until 2.2.

If additional defects related to a new drop of Fusion and RFC 60 are found in 2.1, those can be fixed in 2.1.1 because they are simply defects on a released feature.
 

Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Morrison
Sent: September 18, 2009 12:07 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Here I go sticking my nose in where it probably doesn't belong again...

In my mind if we add RFC60 and Fusion fixes/updated version we are going to need to start completely over on the testing at the beta stage.  (forget release candidate status).  I'm not knocking any of the fixes/changes that are in these, I'm just saying we can't keep adding new features without an end in sight.  (yes, I consider the Fusion fixes a new feature)  Do a release 2.11 in a month or so and put these fixes in.  Just don't keep holding a final 2.1 release pending more bigger and better things.

I will go wipe my nose now...

Martin


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 1:49 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".


Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?


Thanks,
Trevor


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
 
Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this
additional functionality  I only been shown some unit test code and
never a real map.
For the complexity of this feature this is not sufficient and I am still
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60,
a simple addition in functionality, would do no harm and not disturb any
maps using new stylization.

I am very disappointed about working months for this project an nobody
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the
missing patch is very visible
on his site. thank you very much.


to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[UV-2]

> Yes, I refuse to use a beta or release candidate on a production box as a matter of policy/liability.
>
> Thanks
we cant even use a release candidate any longer but have to patch with
RFC60 ourselves.... for production of course!

I still hope that somebody will come up with a big map using new
stylization for me before I am too busy to look into it anymore
so we can tackle the remaining issue at the root.

My second merge with the 2.1 branch already caused a few days extra
work... (or lets call it waste of time ;)
having a new stylization map I also could verify that the patch does not
cause problems with new stylization even without any changes...

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Walt Welton-Lair]

I think you should create your own test map - it's not hard.  Use one of your existing tiled maps, and modify a couple of your layer definitions to use the new stylization.

Start by looking in the UnitTest\TestData\Symbology folder.  It contains sample symbols / layers used by the unit test.

  - the .sd files are sample symbol definitions (point / line /area)
      * symbol.sd / symbol.sd are point symbols
      * linesymbol.sd is a line symbol
      * areasymbol.sd is an area symbol

  - the .ldf files are sample layer definitions that reference these symbols - pay attention to the SymbolInstance element
      * UT_SymbologyPoints.ldf - an example of a layer referencing a point symbol
      * UT_SymbologyLines.ldf - an example of a layer referencing a line symbol
      * UT_SymbologyParcels.ldf - an example of a layer referencing an area symbol

To convert a layer to use the new stylization, replace any PointTypeStyle / LineTypeStyle / AreaTypeStyle element with a CompositeTypeStyle element, like in the unit test layer files.  You'll then want to do two tests with the layer (you'll want your RFC60 code to handle both):

1) Test using referenced symbol definitions.  This is what the .ldf files currently have.  The SymbolInstance contains a ResourceId element indicating which SymbolDefinition resource to use.  Obviously you'll need to add the symbol definitions to the repository.  I know MapGuide Studio lets you easily create them, or you can add them by hand using the Web forms.  One nice thing about using referenced symbols is that in a *debug* build you can make the ReferenceId point to a file on your machine, e.g.:

            <SymbolInstance>
              <ResourceId>C:\Temp\Symbols\SymbologyLines.sd</ResourceId>
              ...
            </SymbolInstance>

You can then easily edit the symbol to test different behaviors, without having to upload it all the time.

2) Test using inlined symbol definitions.  Instead of using a ResourceId tag just embed the SymbolDefinition directly, e.g.:
            <SymbolInstance>
                <SimpleSymbolDefinition>
                    ...
                </SimpleSymbolDefinition>
            </SymbolInstance>



Of course you'll want to test using different symbol definitions.  Refer to the schema and RFC 14 for this.  Again, once you get a layer set up which uses a referenced symbol on your hard drive then it's very easy to test.  I also attached a zip with symbols + layers I've used in my testing.  You'll have to sort through it though.

Walt

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: Friday, September 18, 2009 6:17 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 ??? - at least a sandbox please


> Yes, I refuse to use a beta or release candidate on a production box as a matter of policy/liability.
>
> Thanks
we cant even use a release candidate any longer but have to patch with
RFC60 ourselves.... for production of course!

I still hope that somebody will come up with a big map using new
stylization for me before I am too busy to look into it anymore
so we can tackle the remaining issue at the root.

My second merge with the 2.1 branch already caused a few days extra
work... (or lets call it waste of time ;)
having a new stylization map I also could verify that the patch does not
cause problems with new stylization even without any changes...

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Walt Welton-Lair]

And as usual the attached file (24Kb) didn't make it.  Definitely a PITA.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Walt Welton-Lair
Sent: Friday, September 18, 2009 6:57 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

I think you should create your own test map - it's not hard.  Use one of your existing tiled maps, and modify a couple of your layer definitions to use the new stylization.

Start by looking in the UnitTest\TestData\Symbology folder.  It contains sample symbols / layers used by the unit test.

  - the .sd files are sample symbol definitions (point / line /area)
      * symbol.sd / symbol.sd are point symbols
      * linesymbol.sd is a line symbol
      * areasymbol.sd is an area symbol

  - the .ldf files are sample layer definitions that reference these symbols - pay attention to the SymbolInstance element
      * UT_SymbologyPoints.ldf - an example of a layer referencing a point symbol
      * UT_SymbologyLines.ldf - an example of a layer referencing a line symbol
      * UT_SymbologyParcels.ldf - an example of a layer referencing an area symbol

To convert a layer to use the new stylization, replace any PointTypeStyle / LineTypeStyle / AreaTypeStyle element with a CompositeTypeStyle element, like in the unit test layer files.  You'll then want to do two tests with the layer (you'll want your RFC60 code to handle both):

1) Test using referenced symbol definitions.  This is what the .ldf files currently have.  The SymbolInstance contains a ResourceId element indicating which SymbolDefinition resource to use.  Obviously you'll need to add the symbol definitions to the repository.  I know MapGuide Studio lets you easily create them, or you can add them by hand using the Web forms.  One nice thing about using referenced symbols is that in a *debug* build you can make the ReferenceId point to a file on your machine, e.g.:

            <SymbolInstance>
              <ResourceId>C:\Temp\Symbols\SymbologyLines.sd</ResourceId>
              ...
            </SymbolInstance>

You can then easily edit the symbol to test different behaviors, without having to upload it all the time.

2) Test using inlined symbol definitions.  Instead of using a ResourceId tag just embed the SymbolDefinition directly, e.g.:
            <SymbolInstance>
                <SimpleSymbolDefinition>
                    ...
                </SimpleSymbolDefinition>
            </SymbolInstance>



Of course you'll want to test using different symbol definitions.  Refer to the schema and RFC 14 for this.  Again, once you get a layer set up which uses a referenced symbol on your hard drive then it's very easy to test.  I also attached a zip with symbols + layers I've used in my testing.  You'll have to sort through it though.

Walt

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: Friday, September 18, 2009 6:17 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 ??? - at least a sandbox please


> Yes, I refuse to use a beta or release candidate on a production box as a matter of policy/liability.
>
> Thanks
we cant even use a release candidate any longer but have to patch with
RFC60 ourselves.... for production of course!

I still hope that somebody will come up with a big map using new
stylization for me before I am too busy to look into it anymore
so we can tackle the remaining issue at the root.

My second merge with the 2.1 branch already caused a few days extra
work... (or lets call it waste of time ;)
having a new stylization map I also could verify that the patch does not
cause problems with new stylization even without any changes...

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Walt Welton-Lair]

UV - I've sent you the file

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Walt Welton-Lair
Sent: Friday, September 18, 2009 6:59 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

And as usual the attached file (24Kb) didn't make it.  Definitely a PITA.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Walt Welton-Lair
Sent: Friday, September 18, 2009 6:57 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

I think you should create your own test map - it's not hard.  Use one of your existing tiled maps, and modify a couple of your layer definitions to use the new stylization.

Start by looking in the UnitTest\TestData\Symbology folder.  It contains sample symbols / layers used by the unit test.

  - the .sd files are sample symbol definitions (point / line /area)
      * symbol.sd / symbol.sd are point symbols
      * linesymbol.sd is a line symbol
      * areasymbol.sd is an area symbol

  - the .ldf files are sample layer definitions that reference these symbols - pay attention to the SymbolInstance element
      * UT_SymbologyPoints.ldf - an example of a layer referencing a point symbol
      * UT_SymbologyLines.ldf - an example of a layer referencing a line symbol
      * UT_SymbologyParcels.ldf - an example of a layer referencing an area symbol

To convert a layer to use the new stylization, replace any PointTypeStyle / LineTypeStyle / AreaTypeStyle element with a CompositeTypeStyle element, like in the unit test layer files.  You'll then want to do two tests with the layer (you'll want your RFC60 code to handle both):

1) Test using referenced symbol definitions.  This is what the .ldf files currently have.  The SymbolInstance contains a ResourceId element indicating which SymbolDefinition resource to use.  Obviously you'll need to add the symbol definitions to the repository.  I know MapGuide Studio lets you easily create them, or you can add them by hand using the Web forms.  One nice thing about using referenced symbols is that in a *debug* build you can make the ReferenceId point to a file on your machine, e.g.:

            <SymbolInstance>
              <ResourceId>C:\Temp\Symbols\SymbologyLines.sd</ResourceId>
              ...
            </SymbolInstance>

You can then easily edit the symbol to test different behaviors, without having to upload it all the time.

2) Test using inlined symbol definitions.  Instead of using a ResourceId tag just embed the SymbolDefinition directly, e.g.:
            <SymbolInstance>
                <SimpleSymbolDefinition>
                    ...
                </SimpleSymbolDefinition>
            </SymbolInstance>



Of course you'll want to test using different symbol definitions.  Refer to the schema and RFC 14 for this.  Again, once you get a layer set up which uses a referenced symbol on your hard drive then it's very easy to test.  I also attached a zip with symbols + layers I've used in my testing.  You'll have to sort through it though.

Walt

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: Friday, September 18, 2009 6:17 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 ??? - at least a sandbox please


> Yes, I refuse to use a beta or release candidate on a production box as a matter of policy/liability.
>
> Thanks
we cant even use a release candidate any longer but have to patch with
RFC60 ourselves.... for production of course!

I still hope that somebody will come up with a big map using new
stylization for me before I am too busy to look into it anymore
so we can tackle the remaining issue at the root.

My second merge with the 2.1 branch already caused a few days extra
work... (or lets call it waste of time ;)
having a new stylization map I also could verify that the patch does not
cause problems with new stylization even without any changes...

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[UV-2]

hi tom,

found the sandbox... however i have not shared my user id :) its
uvlite
I suppose the password should be set and mailed to me personally so i
can change it after....

cheers,
UV

Tom Fukushima wrote:

> Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.
>
> Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
> Sent: Friday, September 18, 2009 10:57 AM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please
>
> Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.
>
> I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?
>
> Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
>  
> Thanks,
> Trevor
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
> Sent: September 18, 2009 9:28 AM
> To: MapGuide Internals Mail List
> Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please
>
> It seems like RFC60 will not be included in any release on the basis
> that it does not support the new stylization.
> In this context I would like to request a sandbox to be able to upload
> at least a working configuration.
> Adapting the pach to the ever changing code base is an ever increasing task.
>
> i have been asking a few times for sample test maps to implement this
> additional functionality  I only been shown some unit test code and
> never a real map.
> For the complexity of this feature this is not sufficient and I am still
> lacking resources to do an efficient job.
> Furthermore nobody seems to use that stylization so it seems that RFC60,
> a simple addition in functionality, would do no harm and not disturb any
> maps using new stylization.
>
> I am very disappointed about working months for this project an nobody
> would even allow me to
> contribute anything to the code base after fixing the issues in the patch.
> something seems missing in the open source here ...
>
> our customer now has a big problem to continue with updating MGOS as the
> missing patch is very visible
> on his site. thank you very much.
>
>
> to keep at least the code base i am requesting
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>  

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[UV-2]

thanks for the samples walt,
I will have a go on this. I really want this off the table.

I tried writing to the sandbox.... however a user need to be set up
please use the username  "uvlite" I use for the website.

I hope a decision can be made soon regarding the branch to use.
Playing with a repository on a long remote line is not very productive
work....

cheers
UV
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Tom Fukushima]

OK, I've added uvlite as a committer. This page describes how to manage your OSGeo user id: http://www.osgeo.org/osgeo_userid/.

Cheers
Tom

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
Sent: Saturday, September 19, 2009 5:22 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 ??? - at least a sandbox please USERID

hi tom,

found the sandbox... however i have not shared my user id :) its
uvlite
I suppose the password should be set and mailed to me personally so i
can change it after....

cheers,
UV

Tom Fukushima wrote:

> Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.
>
> Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
> Sent: Friday, September 18, 2009 10:57 AM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please
>
> Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.
>
> I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?
>
> Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.
>  
> Thanks,
> Trevor
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of UV
> Sent: September 18, 2009 9:28 AM
> To: MapGuide Internals Mail List
> Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please
>
> It seems like RFC60 will not be included in any release on the basis
> that it does not support the new stylization.
> In this context I would like to request a sandbox to be able to upload
> at least a working configuration.
> Adapting the pach to the ever changing code base is an ever increasing task.
>
> i have been asking a few times for sample test maps to implement this
> additional functionality  I only been shown some unit test code and
> never a real map.
> For the complexity of this feature this is not sufficient and I am still
> lacking resources to do an efficient job.
> Furthermore nobody seems to use that stylization so it seems that RFC60,
> a simple addition in functionality, would do no harm and not disturb any
> maps using new stylization.
>
> I am very disappointed about working months for this project an nobody
> would even allow me to
> contribute anything to the code base after fixing the issues in the patch.
> something seems missing in the open source here ...
>
> our customer now has a big problem to continue with updating MGOS as the
> missing patch is very visible
> on his site. thank you very much.
>
>
> to keep at least the code base i am requesting
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>  

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals