[mapguide-internals] Double standards from AD- Sandboxes now:)

Thu Jul 16 14:50:57 EDT 2009

I'd like to apologize to the community on behalf of the development team. We are proud to consider ourselves members of this community, and it was never our intention to give the impression of having a double standard. The code changes that have so far been submitted to the trunk stream will be reverted immediately.

Chris.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Wednesday, July 15, 2009 10:36 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] Double standards from AD- Sandboxes now:)

I really take issue with the comments which i find to show complete
and utter double
standards for the way non autodesk people have been treated on this
'open-source'
project by AD.

two attempts from external devs (uv, helio) other than autodesk have
been hindered by
autodesk staff citing reasons why can't have commit rights. then this happens.

still no sandboxes and yet AD cites budget constraints, well i can say from
personal experience, big deal, it happens to everyone, the RFC60 work
was a budget
problem for me, for the same reasons :( not good enough..

I really really appreciate the efforts of the AD mapguide team, but if
your going to
run/oversee a  successful open source project, as a company you need to dedicate
more resources to eliminate the blocks which your raising as objections before
others can participate.

and this is all simple as getting sandboxes up and running!

the RFC60 maps looks great BTW

and a apt-get install mapguide-server on ubuntu  would really help
adoption in a big way

z

On Thu, Jul 16, 2009 at 1:16 AM, Chris
Claydon<chris.claydon at autodesk.com> wrote:
> Hi Jason,
> snip
>
> In a separate email you raised a concern about the recent submissions against the as-yet-unapproved RFC. The purpose of these submissions was to allow collaboration between various developers at remote sites, allowing them to gain access to, and to build upon the underlying print-layout-related classes. The classes in question are essentially isolated from the rest of the MapGuide code base, and any APIs they contain are internal. So there is very low risk of their introducing any destabilization. I appreciate that in order to conform strictly to the open source development process, these submissions should not have occurred prior to the final approval of the RFC, or should have been made in a sandbox project. Unfortunately, by delaying the collaboration process, or by adding the additional overhead of updating the build processes and related projects to reference a sandbox, the entire development on this feature would have been jeopardized. The code submitted so far should be considered an initial revision, and will be updated as necessary to reflect changes that stem from the review of the RFC. If you still have concerns over the presence of this code in the subversion vault, please let me know.
>
> Thank you again for your help in ensuring that we design this the right way!
>
> Cheers,
>
> Chris.
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
> Sent: Monday, June 22, 2009 9:50 PM
> To: MapGuide Internals Mail List
> Cc: Reva Revadigar
> Subject: RE: [mapguide-internals] MapGuide RFC 67 - Common Print Layout and Print Layout Elements ready for review
>
> I'll reply to the middle one for luck :)
>
> In general, I feel that some parts of this are a bit too tightly bound to client software rather than server software, but perhaps there is some benefit in being able to persist device and media settings on the server side if we ever get a rich client such as Flex or HTML5?  I don't think that we have access to these client settings from the server otherwise.  I also wonder a bit about clarity with this new service having so many overlaps with existing MapGuide funcionality; are any deprecations / rewrites planned?
>
> I jumped the gun a bit while this one was still being formed, and asked a few questions.  These questions and Reva's answers are inline.
>
> - You mention PrintLayout schema and service.  Will the Mapping Service be updated to use these rather than the current combination of programmatic (MgPlotSpecification) and schema (MgLayout) methods?  Is any thought being given to how this could be applied to a generic service that would allow the output of HTML+CSS / PDF / DWF output?
>
> RR: Chris may be better able to answer this
>
> - Are the units for PrintLayout/PaperSize always of a given type (mm?).  If not, should "units" be part of the Size2dType or a separate attribute of the PrintLayout?  The MgPlotSpecification/pageUnits (MgPageUnitsType) exists for this in the mapping service.
>
> RR: Yes, good catch.  The units must be added to the schema.
>
> - Is there a way to add custom graphics (such as a logo)?  I can't find a PrintLayoutElement for this.
>
> RR: Yes, there will be.  It'll be just another PrintLayoutElement.  Note that we have just begin sketching out the base architecture and schema for some of the print layout element types, but haven't thought about all possible kinds of contents yet.  The model, however, is extensible to accommodate these types though.
>
> - Is there a need to store the device name as part of the print definition?  Doesn't this affect the portability of these items?  I think it might be better to maintain the association between a print layout and allowed devices either in a different resource type or at the application level.
>
> RR:  Hmm...interesting.  Yeah, decoupling the device from the print layout might give flexibility with respect to its usage although it'd be hard to determine some of the aspects such as printable area, etc, but maybe that can be handled somehow.
>
> - What does MediaName "the canonical name of the media" mean?  Is there a list of allowed values?  Is this device-specific like the above?
>
> RR:  The canonical media name is the locale-independent name of the media available on the configured plot device.  It'd typically be a list of allowed values such as "Letter", "A4", etc.
>
> ________________________________________
> From: Bruce Dechant [bruce.dechant at autodesk.com]
> Sent: Monday, June 22, 2009 1:54 PM
> Subject: [mapguide-internals] MapGuide RFC 67 - Common Print Layout and Print Layout Elements ready for review
>
> Please review MapGuide RFC 67 - Common Print Layout and Print Layout Elements.
> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc67_______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

-- 
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals