Hello lawn gardeners,
If you are interested in either "GUI Sections" or a "Metadata Graph" I would
greatly apreciate your comments.
Things I'm thinking about:
GUI Sections:
Add the following to the definition of both struct Option and struct Flag
This option would provide guidance for GUIs in arranging the options.
It can be multiple fields seperated by whatever delimiter is used most often
that isn't a comma.
The gui could then lay out the options in tabs or group them with headers. A
very smart gui might put each smallest section in its own box, calculate its
height, then combine it with other options from the same next largest
section, and if that's larger than the maximum height that the gui is trying
to keep things under then split parts off into tabs.
These strings could be internationalized.
char *guisection; /* GUI Layout guidance */
This would allow the current TCL/TK interface or future GUIs to arrange things
in a more handleable way. Any existing GUI should retain the option of
displaying things the old style way.
This would require changes to:
include/gis.h
lib/gis/parser.c
general/g.parser/main.c
And to any file that ends up at:
$env(GISBASE)/etc/gui.tcl
Metadata Graph:
A metadata graph would keep track of everything that happens to data and would
be able to provide a complete history of what happened to any map.
The following items would be tracked as nodes in the graph:
The graph could have the following types of nodes. *s are optional or perhaps
undesired
An issued command
Versions of elements of named database things (versions of objects)
Unique data nodes (anonymous regions, projection settings, etc)
* A representation of external data (file, data in another location?, etc.)
* Temporary files
These types of nodes would be considered root nodes for garbage collection.
Anything not reachable from them can be removed from the graph.
Versions of elements of named database things
The following would be tracked as subgraphs in the graph:
Shell commands and other compound commands
Edges on graphs would be the following
Edges point OUT TO where data came from.
Edges can be labeled by the effect they had on the data (would require a
module to label them). Expansion of what the parser does (database types, and
io marking) would make this possible with less work for developers.
This would need to be hooked into the G_parser system, into commands that
access data (G__open is fantastic and provides almost all the information we
need), into commands that get significant (meaning altering) data from other
sources (such as current region), and into programs that don't use these
commands, such as the manage programs. It might to also be profitable to hook
it into commands that write to the hist files.
One would also need to keep track of which nodes in the graph are associated
with the current versions of files. This might be a new "element"
Edges need to go between mapsets
Garbage collection works like this:
Read in everything we're interested in (all users all mapsets). Mark
everything that's reachable from any root nodes in any user's mapsets. Delete
any node and edge in this user's this mapset that wasn't marked. It will only
be done when called manually or possibly on exit.
What comes later is slightly less interesting,
--Cedric Shock
File format considerations:
All in one file - possibly too much overhead. It'd be nice to have bite sized
files.
DGlib file format looks like it'd be expensive to write to.
DGlib is already part of grass; I should probably use it.
Graphs will need to be merged (across users and mapsets).
One file per node allows maximum access control to the graph.
One file per user allows just about the same control.
Something needs to give out unique node ids.
Places to insert hooks (procedures):
G_parser : Note the running of a program. Tentatively make command nodes
G__open : Note the opening of files. Commit to writing history graph nodes
once somethign is opened in write mode.
G__get_window? / G_get_default_window / Whatever gets the current region and
default region, assuming these aren't handled by G__open. We might want to
handle regions seperately since not much data defines them.
include/gis.h
lib/gis/parser.c
general/g.parser/main.c
lib/gis/open.c
Modules that would need special attention:
Anything that makes changes without going through open.c:
general/managage/ all of these
Anything that takes in important arguments or data not handled by G_parser:
r.mapcalc (to describe expressions)
Ideas for commands:
G_history_graph_auto(On / Off): Call before G_parser to not have automatic
histroy graph stuff done. Useful for commands with no side effects.
G_history_graph_auto_write(On / Off): Used to not have history graph writen
automatically when a write operation is detected.
G_history_graph_write(): write the history now.
G_history_graph_add_edge (char* element, char* name, char* mapset, int mode):
Add edges and nodes (when writing) to the history graph for versions of files
involved.
More commands to add data to nodes that are around. Some commands that arn't G
(not in gis.h) for querying and modifying the graph. Only commands for adding
nodes to the graph should end up included from gis.h.
Then we'd need a small slew of programs for garbage collection, querying
ascendants and descendants, output to formats like XML, graphvis, etc.