Developer Working Group 3: APIs and Plug-in Architecture

Developer Working Group 3:  APIs and Plug-in Architecture
Session Leader(s): Chris Barnett, Steve McDonald
Background & Agenda:
Many of us would like to extend Open Geoportal or even use different front-end or back-end technologies.  To do this and still share a common code base, we need an architecture that supports plug-ins and has well defined APIs.

Areas for discussion:
1.    current ways to extend and customize Open Geoportal
2.    Use cases.
3.    possibilities for a plug-in architecture; Java and JavaScript
4.    a RESTful or REST-like API for the portal (both for use by the client and externally)
5.    APIs for OGP code itself.  What does a useful API look like?
6.    Prioritize.

The goal of the session is to identify ways to make Open Geoportal more flexible and extensible.  Where possible, concrete implementation ideas should be specified.  Where they cannot be specified, action items will emerge.

Some longer term action items for the DWG are likely to be:
1.    Identification/documentation of de facto OGP APIs.
2.    Identify where same diverge from best practices or are insufficient.
3.    Propose a set of APIs
4.    Implement.
5.    Repeat for Java, JavaScript, RESTful APIs

The following link is a whiteboard to put any thoughts you have on the topic:

Session Notes:

Chris: Spring MVC on backend, supports dependency injection, servlets via config file, abstract issues like downlad

JavaScript: more of a problem
in 2.0, backbone, decoupling, some event passing,
data in backbone or

Mike: OGP is designed for a certain user experience, what would people want to change

Chris: add preview types

Darren: for plugins need to define core
perhaps cart is plug-in
skin as plug-in

Garey: perhaps css plugin

Mike: don’t need cart either
encourage template usage, each one in a separate file
encourage use of require.js: modules wrapped in a define function

Chris: backbone – logic layer with data objects, attributes affected, events fire on event changes and the UI is updated, improves structure of code

Chris: need to identify what is pluggable

Darren: advanced search as plugin

Garey: pop-up info window, selecting correct stylesheet

Darren: redirect to persistent url in another window for info

Chris: consider separation between frontend and backend, potential ogc standard for portals,

Garey: plugin to provide getcapabilities

Garey: security, per layer based on department/group membership

Darren: Stanford uses firewall, uses apache level, all data is restricted
Garey: horde plugin, Apache plugins

Steve: plugin architecture examples? jQuery, Leaflet. no great suggestions.

Chris: how much of this goes into the roadmap

Garey: collection level records

MIke: collection record search could be very different and need a different UI

Darren: just a link to collection information would be useful, Google earth has folders but they don’t work well.

Garey: GeoServer plug of neo4j to deal with relations and nodes to create network data representations of maps

Garey: identify core areas?

Mike: put as much into css as possible

Notes On Plugins From Whiteboard
Client Side:
Cart Actions
Advanced Search
Info Window


Server Side:
Download Method

Preview Controls

Core Code:
List of layers
Mouse over bounding box
Search results
Search box
Preview map
Solr Schema, but it could be abstracted.

Mike: rather than hacking css, use import statement

Garey: results of search only facets and use selects
multiple authentication types supported

Chris: UI is an interface to the index

Location field, a very open field that perhaps need some guidelines

Mike: collection json, define elements of hash

Chris: consider the cart as the first pluggable option, or advanced search

Garey: info window should be easy

Darren: include tooltip for info button behavior

Action Items: