NeoGopher is a universal data browser that presents two things to the user. The first is web pages - which you understand well. The second thing it presents is GopherLists.
A GopherList is a list of data. A GopherList is programmed via a Javascript source code file loaded from a web server. A GopherList retrieves data from any web based API - as long as it is accessible via HTTP and returns XML or JSON then it is a valid data source for a GopherList. This means that a GopherList is compatible with ANY web based data source or XML/JSON data format standard. As long as it returns XML or JSON via HTTP then it can be displayed in a GopherList. So any developer is free to create a GopherList, simply by writing a small amount of Javascript and posting it to a web server.
It's worth noting that a GopherList does not run within a web page and is not related to HTML at all, even though it is programmed using Javascript and even though the links in a GopherList are URL's. Imagine that the GopherList is the missing piece of the world wide web, standing alongside the HTML web page.
Data in a GopherList is organised into rows and columns - just like any ordinary table of data. However, the true power of the GopherList is it pervasive linking. A link may be defined for any row or any individual cell in a GopherList. And any one of these links may lead on to another GopherList, or may lead on to a web page. Any GopherList may link on to any other GopherList - it doesn't matter who created the link target - the developer is free to link any list to any other list - this is just the same as the world wide web where any web page can link on to any other web page. Any row of data in a GopherList may have child rows, and each child row may also contain a link on to either a web page or to another GopherList.
A GopherList may get its data from any web based API. The developer crafts a URL query to the API within the Javascript source code of the GopherList. NeoGopher sends the URL to the API and receives response data from the API. NeoGopher then processes the response data, and looks for repeating elements within the response data. Each time NeoGopher finds a repeating element, it extracts it from the response data and then it through a Javascript function in the GopherList source code. This Javascript function processes the repeated element and turns it into a row of data in the GopherList. This process repeats until all repeated elements have been extracted from the API response data. The GopherList is able to identify repeated elements in the response because the developer specifies the XML tag of a repeated element.
GopherLists support paging, sorting and searching. When certain events happen - for example the user types a value into the search field, or the user scrolls down the list, or the user clicks on a column header to sort, then the GopherList source code re-executes and a new URL is constructed and sent to the API, more data comes back and is processed into rows in the GopherList. So the capabilities of a GopherList are as rich as the capabilities of the API that it talks to - sorting/searching/paging.
Many web based APIs require an API key to get access to the API. If the user loads a GopherList that uses an API with a key, then NeoGopher asks the user for the key and also presents them with the web page that will allow them to request a key.
Many API's require attribution, so the developer is able to specify an HTTP link to be used as attribution - this is displayed at the bottom of the GopherList.
Important note:
NeoGopher is beta code. It is entirely likely that it will crash. In most cases the crash only takes out the NeoGopher application itself but I once saw it freeze the entire operating system. Please ensure you do not have any data that might be lost or applications running that are important when running NeoGopher. We believe NeoGopher is mostly stable but software has a way of crashing nastily when put in the hands of end users. If it does crash we would very much like to know what steps you took to make it crash.