[fdo-dev] fdo and fdocore

[Mateusz Loskot]

Hi Greg,

Greg Boone wrote:
> Hi Mateusz,
> 
> Please bear with me. I will attempt to provide some background
> information over a number of responses.
> 
> NOTE: The OSGeo FDO project is currently not a Live project. It is
> *scheduled* to go live towards the end of July. The site is currently
> under development with a number of changes being made to the look and
> feel of the site as well as source code content found on the site.
> Please be patient as we work towards getting the site up and running. 

That explains much. Frank and I have started our work
on the fdogdal so we move on last 2 days, but certainly
we will keep an eye on the FDO family projects.

> Feature Data Objects (FDO) is an API for manipulating, defining, and
> analyzing geospatial information. FDO uses a provider (or driver) based
> model for supporting a variety of geospatial data sources, where each
> provider typically supports a particular data format or data store.
> Providers exist for accessing data stored in RDBMS formats such as MySQL
> or from file formats such as Shape. 
> 
> To start using FDO, I strongly recommend reading...
> 
> The Essential FDO:
> 
> https://fdo.osgeo.org/docs/FET_TheEssentialFDO.pdf
> 
> FDO Developers Guide:
> 
> https://fdo.osgeo.org/docs/FDG_FDODevGuide.pdf

Yes, I found those documents a few weeks ago and I started from reading
them. They are excelent source of details about FDO.
I noticed they need some update for FDO 3.2.0 (fdocore SVN repository)
but I've managed to recognize main changes between FDO 3.0.0
and 3.2.0. So, those docs are still helpful.

> NOTE: We are also working on a 'How to Build FDO' document that will
> assist users in the specific issues involved with building the various
> components within the FDO architecture.

Great!
For now, I use OpenSourceBuild__README.txt from the fdocore
repository + some analysis of build_*.sh scripts.

> The FDO project structure has been organized into several OSGeo
> subprojects that allow access to the source code of the various
> components with the FDO architecture as separate projects.
> 
> https://fdo.osgeo.org is the top level project and is a starting point
> for discovering components within the FDO architecture. From this site
> the FDO API is introduced and the developer community exposed to the API
> and a set of supported data providers. 

I understand.

> https://fdo.osgeo.org contains a number of Subversion Subprojects:
> 
> fdocore   -- FDO Core APIs            https://fdocore.osgeo.org 
> fdoarcsde -- FDO Provider for ArcSDE  https://fdoarcsde.osgeo.org 
> fdogdal   -- FDO GDAL Provider        https://fdogdal.osgeo.org 
> fdoogr    -- FDO OGR Provider         https://fdoogr.osgeo.org 
> fdordbms  -- FDO Providers for RDBMS  https://fdordbms.osgeo.org 
> fdosdf    -- FDO Provider for SDF     https://fdosdf.osgeo.org 
> fdoshp    -- FDO Provider for SHP     https://fdoshp.osgeo.org 
> fdowfs    -- FDO Provider for WFS     https://fdowfs.osgeo.org 
> fdowms    -- FDO Provider for WMS     https://fdowms.osgeo.org 

I have only access to fdocore (read-only) and fdogdal (read-write).
So, I suppose rest of FDO provides has not been published yet.
But now I know the work is in progres.

> fdocore is the FDO API subversion. The FDO API was placed in the fdocore
> subproject to separate its development from provider development. Access
> rights will be granted to fdocore separately from the subprojects that
> implement the FDO API. 

I understand.

> NOTE: fdocore must be built first so that all other subprojects that
> depend on the FDO API may be built. 

Yes, I revealed it after some small hacking :-)
We (Frank and I) have managed to build fdocore and fdogdal.

> fdocore is composed of three central components
> 
> 1) Fdo: The base FDO API written in portable C++ and compliable in a
> Windows or Linux environment. There is also an additional set of .Net
> managed C++ classes that serve as wrapper classes around the unmanaged
> API and allows the FDO API to be executed from within a Windows .Net
> application. 
> 
> Fdo is primarily composed of:
> 
> [...]

Excelent explanation! Thank you!

> fdocore contains a Providers directory which is empty. This directory is
> meant to be a placeholder under which all provider source can be located
> so that the FDO and Provider source code can be compiled from the top
> level fdocore build scripts. The continues existence of this directory
> may be maintained or abandoned as we move towards the *go live* date.
> 
> e.g.
> 
> ...\Providers\ArcSDE
> ...\Providers\SHP
> ...\Providers\SDF
> ...\Providers\WMS
> ...
> 
> The above directory structure is optional and each Provider can be
> placed in a separate directory tree if required. However, maintaining
> the provider code under Providers will allow maximum reuse of the helper
> scripts provider and will mimic the build setup used by the OSGeo build
> team.

I wondered why the old fdo sources have providers inside the source
tree, but fdocore does not have it.
Now it's clear.
Certainly, such separation make sense.

> Once the source code for fdocore has been downloaded, there are a number
> of helper scripts that can be used to update and build the source code.
> There are versions of these scripts available for Windows and Linux.
> 
> checkoutsvn -- allows the FDO API and provider source code to be updated
> from their appropriate subversions. NOTE: executing this script will
> checkout setup the FDO API and Provider directories in a configuration
> that mimics the internal build configuration. This will mean that all
> OSGeo Provider source code will be retrieved to your development
> location
> 
> setenvironment -- sets the build environment that will allow the FDO API
> and the Providers to be built
> 
> build_thirdparty -- builds the thirdparty components required by the FDO
> API and its providers to run successfully.
> 
> build -- builds the FDO API and Providers on Windows. Executing this
> script with no arguments will build Thirdparty, Fdo, Utilities and all
> Provider retrieved by the checkoutsvn script. 
> 
> build_linux -- builds the FDO API and Providers on Linux. Executing this
> script with no arguments will build Thirdparty, Fdo, Utilities and all
> Provider retrieved by the checkoutsvn script.

Again, thank you for great detailed explanation.
I have some question about build* scripts.
Are those scripts considered as obligated for building FDO projects?
Or are you going to keep autotools universal enough so users will be
able to run them manually and build FDO projects with custom options
e.g. custom --prefix etc.?

After 3-4 days of working on the FDO project, I have an impression
that the installation prefix is fixed, even manually coded in some
places like:
fdocore/Fdo/Unmanaged/Src/Fdo/ClientServices/RegistryUtility.cpp:777

Simply, what's the policy regarding customization of FDO building and
installation.
If you could put some light on this subject too I'd be thankful.

Greg, thanks for your fantastic assistance and comprehensive explanations!

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net