Okay this really looks like we don't communicate well
I understand the need for this, and the benifit it buys us in terms of isolation for test, for clustering etc... But these abstractions are important to me and they should be "developer facing" constructs that module writers see. Their seems to be a 100% overlap with the concerns of the catalog api in this regard.
Let me try and lock this one down ....
MODULE (say WFS)
--- catalog api ----
DATA
--- config api ---
PERSISTENCE
Is this the common operating picture everyone is working against?
Jody
Brent you mentioned that the WEB UI module could be independent of the catalog api .. is this what you are thinking of?
MODULE
-- catalog api ---
| WEB UI
DATA | or
| REST
--- config api ---
PERSISTENCE
Or are we treating the WEB UI as a normal module? Please note that the current situation that we seem to hate has the WEB UI talking directly via the config api (as if it was a PERSISTENCE layer).
Okay this really looks like we don't communicate well
I understand the need for this, and the benifit it buys us in terms of isolation for test, for clustering etc... But these abstractions are important to me and they should be "developer facing" constructs that module writers see. Their seems to be a 100% overlap with the concerns of the catalog api in this regard.
Hmm, I thought i succesfully showed that the two are separate concerns. Although somewhere they have to be tied together, config needs to to resources in catalog. You seemed to agree with me.
This is *just* about persisting the info that GeoServer maintains about data. It is not about persisting anything in the catalog.
It is also about persisting the information that GeoServer maintains about services. Like the options that control how WFS and WMS behave.
-Justin
Let me try and lock this one down ....
MODULE (say WFS)
--- catalog api ----
DATA
--- config api ---
PERSISTENCE
Is this the common operating picture everyone is working against?
Jody
Hmm, I thought i succesfully showed that the two are separate concerns. Although somewhere they have to be tied together, config needs to to resources in catalog. You seemed to agree with me.
This is *just* about persisting the info that GeoServer maintains about data. It is not about persisting anything in the catalog.
It is also about persisting the information that GeoServer maintains about services. Like the options that control how WFS and WMS behave.
I thought you had as well; I think I just need to see the picture. Can you comment on my other ASCII art picture where I ask where the WEB UI module fits? I am trying to see past these GSIP numbers into your design
|------------------------------------------------------------------|
| |
| User Interface |
| |
|----Catalog API----|----Persistence API---|----Dispatching API----|
| | | | |
| live data | Meta data | Services | Service Modules |
| | | | |
|------------------------------------------|-----------------------|
Jody Garnett wrote:
This next question is for Brent,
Brent you mentioned that the WEB UI module could be independent of the catalog api .. is this what you are thinking of?
MODULE
-- catalog api ---
| WEB UI
DATA | or
| REST
--- config api ---
PERSISTENCE
Or are we treating the WEB UI as a normal module? Please note that the current situation that we seem to hate has the WEB UI talking directly via the config api (as if it was a PERSISTENCE layer).
What I mean was for implementation, we could migrate later on to the new catalog system once the new UI is in place if the catalog development came later. It would be a little bit of duplicate work but would allow us to get a release out in between, which would be beneficial to reduce the risk.
I'm not sure yet how the web ui would interact with the catalog, I think I need to prototype some more to get a better feel for it and be able to provide a more accurate answer.
Brent Owens
(The Open Planning Project)
Jody Garnett wrote:
This next question is for Brent,
Brent you mentioned that the WEB UI module could be independent of the catalog api .. is this what you are thinking of?
MODULE
-- catalog api ---
| WEB UI
DATA | or
| REST
--- config api ---
PERSISTENCE
Or are we treating the WEB UI as a normal module? Please note that the current situation that we seem to hate has the WEB UI talking directly via the config api (as if it was a PERSISTENCE layer).
I am going to return to my original model from last spring so we can
use it as a reference point.
- catalog api: is used to list known data, and manage live data
- prefs (if you remember?) are used by modules to store their settings
- each module are required to store their service settings to prefs, and their
per resource settings to against actual resources (wanting to prevent each module from maintaining an
association from resource to an internal datastructure).
- each module can also provide user interface contributions to the the WEB UI
There is of course several short comings to this plan:
- It is not aggressive enough in taking responsibility for configuration. Items like "Style" and "Namespace" are left as a per service module concerns (this would hinder two WFS 1.0 and WFS 1.1 modules from sharing configuration - would they even be able to?)
It does however have a strength:
- it is open ended, no service module gets special treatment by having its resource types explicitly managed
Cheers,
Jody
Hmmm, the picture in my head is more like:
|------------------------------------------------------------------|
| |
| User Interface |
| |
|----Catalog API----|----Persistence API---|----Dispatching API----|
| | | | |
| live data | Meta data | Services | Service Modules |
| | | | |
|------------------------------------------|-----------------------|
Jody Garnett wrote:
This next question is for Brent,
Brent you mentioned that the WEB UI module could be independent of the catalog api .. is this what you are thinking of?
MODULE
-- catalog api ---
| WEB UI
DATA | or
| REST
--- config api ---
PERSISTENCE
Or are we treating the WEB UI as a normal module? Please note that the current situation that we seem to hate has the WEB UI talking directly via the config api (as if it was a PERSISTENCE layer).
What I mean was for implementation, we could migrate later on to the new catalog system once the new UI is in place if the catalog development came later. It would be a little bit of duplicate work but would allow us to get a release out in between, which would be beneficial to reduce the risk.
I understood you, I am trying to isolate "how low" you want the WEB UI to go? Is it talking straight to the persistence layer? Can you limit it to just working with the catalog api? I think you can, but I want to know what your thoughts are.
I'm not sure yet how the web ui would interact with the catalog, I think I need to prototype some more to get a better feel for it and be able to provide a more accurate answer.
Brent perhaps if you ask questions? uDig has been working against the a catalog api for a while? The existing data api does form a catalog api - but as the GeoTools proposal shows we have learned since then.
I am going to return to my original model from last spring so we can
use it as a reference point.
- catalog api: is used to list known data, and manage live data
- prefs (if you remember?) are used by modules to store their settings
- each module are required to store their service settings to prefs, and their
per resource settings to against actual resources (wanting to prevent each module from maintaining an
association from resource to an internal datastructure).
- each module can also provide user interface contributions to the the WEB UI
That is, Data is a module that other modules depend
onto, handles and hides the crazy gt2 catalog API, keeping
it in a jail and throwing away the key so nobody else
gets to see it, and providing an higher level API that
talks real things, not geo-resources. Every module
talks to a configuration persistence API to gather his
config informations.
Ah ASCII art A picture made of a thousand words...
Andrea Aime wrote:
That is, Data is a module that other modules depend
onto, handles and hides the crazy gt2 catalog API, keeping
it in a jail and throwing away the key so nobody else
gets to see it, and providing an higher level API that
talks real things, not geo-resources. Every module
talks to a configuration persistence API to gather his
config informations.
Heh; See my other email - this scenario is one I only figured out yesterday.
Let's give this one a rest for a bit and think on the matter.
