OSGeo.org › OSGeo Software and Data Projects › MapGuide Open Source › MapGuide Internals

Double standards from AD- Sandboxes now:)

5 messages

Double standards from AD- Sandboxes now:)

Reply Threaded

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<[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 [[hidden email]]
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

Chris Claydon

RE: Double standards from AD- Sandboxes now:)

Reply Threaded

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: [hidden email] [mailto:[hidden email]] 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<[hidden email]> wrote:

--
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
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

Chris Claydon

RFC 67 Updated - Ready for review

Reply Threaded

In reply to this post by zspitzer

Hi All,

I have updated RFC67 with an overhaul of the proposed schema (which includes some cleanup and renaming of elements, addition of annotations, and new definitions for supporting migration from the old MapGuide PrintLayout format to the new PrintLayoutDefinition format), updated diagrams, and a section defining the mapping from the PrintLayout-1.0.0 schema elements to the new PrintLayoutDefinition-2.0.0 schema.

Please review the updated RFC and respond to this mailing list with any questions or comments.

Thanks,

Chris.

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

Trevor Wekel

RE: RFC 67 Updated - Ready for review

Reply Threaded

Hi Chris, a few comments on the RFC:

MgPrintLayoutElementBase and the corresponding schema seem appropriate. The inclusion of optional stylization and data elements allows for very complex geometries to be drawn on the print. This could have all kinds of interesting applications including "generated on the fl " dynamic views in a print layout.

MgPrintLayoutServiceBase printLayoutService = ServiceFactory::GetService(MgResourceType::PrintLayout);

Should probably be

MgPrintLayoutServiceBase printLayoutService = siteConnection.CreateServicee(MgResourceType::PrintLayout);

If MapView is intended to be used in MapGuide, it might be good to make it optional. Center and Scale (ie Center and Height in MapViewType) can be pulled directly from the MgMap. In addition, ViewDirection and Rotation may not be supported by MapGuide.

Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon
Sent: Monday, July 20, 2009 9:46 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC 67 Updated - Ready for review

Hi All,

I have updated RFC67 with an overhaul of the proposed schema (which includes some cleanup and renaming of elements, addition of annotations, and new definitions for supporting migration from the old MapGuide PrintLayout format to the new PrintLayoutDefinition format), updated diagrams, and a section defining the mapping from the PrintLayout-1.0.0 schema elements to the new PrintLayoutDefinition-2.0.0 schema.

Please review the updated RFC and respond to this mailing list with any questions or comments.

Thanks,

Chris.

_______________________________________________
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

Chris Claydon

RE: RFC 67 Updated - Ready for review

Reply Threaded

Thanks for your feedback Trevor. I have updated the RFC with an addendum describing the changes.

Chris.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Thursday, July 23, 2009 2:27 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: RFC 67 Updated - Ready for review

Hi Chris, a few comments on the RFC:

MgPrintLayoutElementBase and the corresponding schema seem appropriate. The inclusion of optional stylization and data elements allows for very complex geometries to be drawn on the print. This could have all kinds of interesting applications including "generated on the fl " dynamic views in a print layout.

MgPrintLayoutServiceBase printLayoutService = ServiceFactory::GetService(MgResourceType::PrintLayout);

Should probably be

MgPrintLayoutServiceBase printLayoutService = siteConnection.CreateServicee(MgResourceType::PrintLayout);

If MapView is intended to be used in MapGuide, it might be good to make it optional. Center and Scale (ie Center and Height in MapViewType) can be pulled directly from the MgMap. In addition, ViewDirection and Rotation may not be supported by MapGuide.

Thanks,
Trevor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Claydon
Sent: Monday, July 20, 2009 9:46 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC 67 Updated - Ready for review

Hi All,

I have updated RFC67 with an overhaul of the proposed schema (which includes some cleanup and renaming of elements, addition of annotations, and new definitions for supporting migration from the old MapGuide PrintLayout format to the new PrintLayoutDefinition format), updated diagrams, and a section defining the mapping from the PrintLayout-1.0.0 schema elements to the new PrintLayoutDefinition-2.0.0 schema.

Please review the updated RFC and respond to this mailing list with any questions or comments.

Thanks,

Chris.

_______________________________________________
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