[mapguide-dev] Unmanaged Data APIs RFC

[Zak James]

Tom,

It didn't come across that way... I was just seeking clarification on  
what would happen to the existing capability and I have that, so I'm  
happy.

zak
--
Zak James
Applications and Software Development
DM Solutions Group Inc.
http://www.dmsolutions.ca


On 9 Nov 2006, at 00:01, Tom Fukushima wrote:

> Hi Zak,
>
> Sorry, I didn't mean for my suggestion to sound like an edict.  I  
> only meant to propose that as the way things should work.  If no  
> one finds a problem with that suggestion, I'll get it put into the  
> RFC.
>
> Cheers
> Tom
>
> 	-----Original Message-----
> 	From: Zak James [mailto:zjames at dmsolutions.ca]
> 	Sent: Wed 2006/11/08 21:10
> 	To: dev at mapguide.osgeo.org
> 	Cc:
> 	Subject: Re: [mapguide-dev] Unmanaged Data APIs RFC
> 	
> 	
>
> 	Tom,
> 	
> 	I think we will definitely be supporting the new API once it's
> 	available, but in light of what you've said, the current approach is
> 	still valid and I don't see a reason to stop users from creating
> 	feature sources from unmapped data sources.
> 	
> 	Thanks for the clarification.
> 	
> 	zak
> 	--
> 	Zak James
> 	Applications and Software Development
> 	DM Solutions Group Inc.
> 	http://www.dmsolutions.ca
> 	
> 	
> 	On 8 Nov 2006, at 23:03, Tom Fukushima wrote:
> 	
> 	> Hi Zak,
> 	>
> 	> I don't want to lock down the server so that it is restricted to  
> those
> 	> files in the Unmanaged Data Mappings. In other words, this means
> 	> that a
> 	> feature source can still reference a file that is not in one of the
> 	> subdirectories specified by the mappings. The reason we don't  
> have to
> 	> restrict to those subdirectories is because we can use the  
> operating
> 	> system's or network's built-in security to limit access to files
> 	> (hopefully they've allowed access to the files in the Unmanaged  
> Data,
> 	> otherwise they won't be very useful :) ).
> 	>
> 	> Will WebStudio use the new APIs instead of allowing the  
> enumeration of
> 	> arbitrary directories?
> 	>
> 	> Tom
> 	>
> 	> -----Original Message-----
> 	> From: Zak James [mailto:zjames at dmsolutions.ca]
> 	> Sent: Friday, November 03, 2006 9:15 PM
> 	> To: dev at mapguide.osgeo.org
> 	> Subject: Re: [mapguide-dev] Unmanaged Data APIs RFC
> 	>
> 	> This is a minor compatibility issue, but the current version of
> 	> webstudio allows the user to specify an unmanaged feature source
> 	> with an
> 	> arbitrary server path and then enumerates files in that path.
> 	> Obviously, there are some security issues with this, but is that
> 	> functionality going to disappear with the changes proposed in  
> the RFC?
> 	>
> 	> If so, I think that needs to be stated in the Proposed Changes
> 	> section.
> 	>
> 	> zak
> 	> --
> 	> Zak James
> 	> Applications and Software Development
> 	> DM Solutions Group Inc.
> 	> http://www.dmsolutions.ca
> 	>
> 	>
> 	> On 3 Nov 2006, at 20:57, Jason Birch wrote:
> 	>
> 	>> Looks good.
> 	>>
> 	>> I would personally prefer to see a single delimiter in the  
> returned
> 	>> list, as it's slightly easier to deal with in code.
> 	>>
> 	>> I'm probably overly sensitive to this, but I'm wondering if the
> 	>> resource list will be cached on the server?  I know that the 6.5
> 	>> MapGuide author caches the responses internally.  I have to hit
> 	>> "update" to get a new list if something (data store, feature  
> source,
> 	>> feature source schema) changes in the current session.  Can we  
> count
> 	>> on the clients doing this to prevent unnecessary network traffic
> 	>> re-enumerating the resources?
> 	>>
> 	>> Jason
> 	>>
> 	>>
> 	>> ________________________________
> 	>>
> 	>> From: Tony Fang [mailto:tony.fang at autodesk.com]
> 	>> Sent: Fri 2006-11-03 4:41 PM
> 	>> To: dev at mapguide.osgeo.org
> 	>> Subject: RE: [mapguide-dev] Unmanaged Data APIs RFC
> 	>>
> 	>>
> 	>>
> 	>> I've updated the RFC with the drive mappings suggestion. Any  
> feedback
> 	>> on the returned list of drive mappings (using square brackets  
> on the
> 	>> drive mapping name) would be appreciated.
> 	>>
> 	>>
> 	>>
> 	>>
> 	>>
> 	>> The server's unmanaged data directories will be specified using  
> the
> 	>> serverconfig.ini. A new section defining directory mappings  
> will be
> 	>> used to specify the unmanaged data directories.
> 	>>
> 	>> For windows, it may look like this:
> 	>>
> 	>> [Unmanaged Data Mappings]
> 	>> SomeSdfFiles = c:\mydata\sdf
> 	>> Some Shp Files = d:\otherdata\shp
> 	>> BigArseImages = \\some_other_machine\data\images
> 	>> Some ???? DwfFiles = c:\mydata\????Dwf
> 	>> ??sdf = c:\mydata\bigsdf
> 	>>
> 	>> For linux, it may look like this:
> 	>>
> 	>> [Unmanaged Data Mappings]
> 	>> SomeSdfFiles = /usr/mydata/sdf
> 	>> Some Shp Files = /usr/otherdata/shp
> 	>> BigArseImages = /mnt/some_other_machine/data/images
> 	>> Some ???? DwfFiles = /usr/mydata/????Dwf
> 	>> ??sdf = /usr/mydata/bigsdf
> 	>>
> 	>> Unicode characters are supported in the mapping names. Spaces in
> 	>> the mappings are also supported. Square brackets [ and ] are not
> 	>> allowed. They are reserved characters for the serverconfig.ini
> 	>> section titles.
> 	>>
> 	>> We will add API methods to return the unmanaged data mappings, set
> 	>> the mappings, and also verify that the mappings are valid and
> 	>> accessible.
> 	>>
> 	>> We will add an API to enumerate the unmanaged data files available
> 	>> on the server machine. The files will be prefaced with their
> 	>> mapping names. You may enumerate all files from all the available
> 	>> drive mappings, or you may select a single drive mapping.
> 	>>
> 	>> A returned list from all available drive mappings may look like  
> this:
> 	>>
> 	>> [SomeSdfFiles]world.sdf
> 	>> [Some Shp Files]ecuador.shp
> 	>> [Some ???? DwfFiles]large.dwf
> 	>> [Some ???? DwfFiles]subdir/Big.dwf
> 	>> [??sdf]reallybig.sdf
> 	>>
> 	>>
> 	>>
> 	>>
> 	>>
> 	>> Thanks,
> 	>>
> 	>> Tony
> 	>>
> 	>>
> 	>>
> 	>> ________________________________
> 	>>
> 	>> From: Robert Bray [mailto:rbray at robertbray.net]
> 	>> Sent: Friday, November 03, 2006 9:05 AM
> 	>> To: dev at mapguide.osgeo.org
> 	>> Subject: Re: [mapguide-dev] Unmanaged Data APIs RFC
> 	>>
> 	>>
> 	>>
> 	>> Jason,
> 	>>
> 	>> Good questions. In addition I think it would make sense / be  
> highly
> 	>> desirable for all RFCs that add or modify APIs to include more
> 	>> detail with respect to those changes. It would be nice to see the
> 	>> actual API function signatures for example.
> 	>>
> 	>> Bob
> 	>>
> 	>>
> 	>> Jason Birch wrote:
> 	>>
> 	>> That would be cool.  That way we can have a theme, and a nested
> 	>> hierarchy within that theme if we need the complexity.  Are we
> 	>> restricted to single-word mappings, or will spaces be supported?
> 	>> ASCII characters only or full internationalisation?
> 	>>
> 	>> What about schema changes?  Will there be a way of updating the
> 	>> repository's knowledge of unmanaged data schemae?  Or are these
> 	>> maybe cached on a session basis like the RDBMS schemae?
> 	>>
> 	>> There would also need to be a method that allows the author UIs to
> 	>> validate resources that reference unmanaged data sources, to make
> 	>> sure that any dependancies (properties, maptips, themes, etc) are
> 	>> still valid, and give a graphical indication when the world slips.
> 	>>
> 	>> Jason
> 	>>
> 	>> ________________________________
> 	>>
> 	>> From: Robert Bray [mailto:rbray at robertbray.net]
> 	>> Sent: Thu 2006-11-02 10:46 PM
> 	>> To: dev at mapguide.osgeo.org
> 	>> Subject: Re: [mapguide-dev] Unmanaged Data APIs RFC
> 	>>
> 	>>
> 	>> I too am concerned this will make data management hard for people
> 	>> with lots of data / multiple projects. It might be better to
> 	>> dedicate a section in serverconfig.ini to define path mappings as
> 	>> follows:
> 	>>
> 	>> [Path Mappings]
> 	>> SomeSdfFiles = <some path>
> 	>> SomeShpFiles = <some other path>
> 	>> BigArseImages = <path to SAN disk>
> 	>> ...
> 	>>
> 	>> In Studio / Web Studio the user would be presented the list of  
> path
> 	>> mappings. Once they select a path mapping they can browse all  
> files
> 	>> and folders below that path.
> 	>>
> 	>> My 2 cents...
> 	>>
> 	>> Bob
> 	>>  
> ---------------------------------------------------------------------
> 	>
> 	>> To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org For
> 	>> additional commands, e-mail: dev-help at mapguide.osgeo.org
> 	>> <winmail.dat>
> 	>>  
> ---------------------------------------------------------------------
> 	>> To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org
> 	>> For additional commands, e-mail: dev-help at mapguide.osgeo.org
> 	>
> 	>
> 	>  
> ---------------------------------------------------------------------
> 	> To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org
> 	> For additional commands, e-mail: dev-help at mapguide.osgeo.org
> 	>
> 	>
> 	>
> 	>  
> ---------------------------------------------------------------------
> 	> To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org
> 	> For additional commands, e-mail: dev-help at mapguide.osgeo.org
> 	>
> 	
> 	
> 	---------------------------------------------------------------------
> 	To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org
> 	For additional commands, e-mail: dev-help at mapguide.osgeo.org
> 	
> 	
>
> <winmail.dat>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org
> For additional commands, e-mail: dev-help at mapguide.osgeo.org