Discuss Redesign of the Connector Interfaces?

[ridoo]

For remote services it is unlikely that the Ilwis connector separation to load (meta-)data fits the way remote data sources (e.g. WFS, ...) provide their data. How the data is assembled is different case-by-case. There is no optimal way for each service and should not be enforced by implementing ContainerConnector, CatalogConnector, ObjectConnector.

These interfaces could be merged together so for a developer there is a single implementation point to focus on. It still can provide separated methods like loadMetadata() and loadBinaryData()

[MartinSchouwenburg]

Disagree. WFS (and other OGC) services provide a clear seperation between metadata and non-metadata. WFS for example has the getcapabilities and the describefeature for what is metadata, while the getfeatures represent the actual data (bulk). It would be a bad design of any service if their metadata wasnt searchable/accessible without needing the bulk data. The seperation catalogconnector/objectconnector formalizes this difference.

[ridoo]

What I mean actually is that the way the connectors are being used by the framework does the developer enforce to place functionality for the one data source in a container connector and for another data source in the catalog connector ... for example, before ilwis framework loads any data source (meta-)data, it has to

1. check data source available with the container connector
2. create data resources via data source links created by the container (this is done by the catalog connector)
3. create data instances by a feature connector (or similar)

first two steps would require a GetCapabilities request, one to create the links to the features (a GetFoi request for each feature type listed in capabiliites), and one to get the metadata to create the actual resources. Sure, the developer could decide where to create and add resources, but then separating these connector tasks to different framework classes makes no sense and leads to more confusion then to clear structural design.

[MartinSchouwenburg]

eeh. no? The container connector is for ogc services for the moment not very relevant. It is used (but that has to be implemented yet) for things like zip files or similar container like files, or ftp sites. The rest is about seperating responsibilities. The catalogconnector has indeed the getcapabilities/describefeature stuff. The object connector builds, if a datasource is selected to be fully loaded, based on the resource information a full url for getfeatures. I don't see the problem there.

[ridoo]

Don't get me wrong here. Separating responsibilities is a good thing!

Perhaps it is just a documentation issue: Adding a WFS instance to the Ilwis framework by setting it as working catalog seemed reasonable to me. I saw this way of adding a working location in your system tests. This however required to have a container connector in place.

[pokulo]

Martin is working on the joined Container/Catalog, which will end up as a regular IlwisObject....