Synoptic library API

[GoogleCodeExporter]

Why is this enhancement useful?

With the Swing and GWT GUIs we are moving towards a model in which there is a 
core Synoptic library and then there is other code that uses this library as a 
blackbox.

To maximize code re-use and to simplify future blackbox uses of Synoptic we 
need to design a Synoptic library API. It will have the following two 
requirements at its core:
- Expose flexibility, so that the client code can selectively turn on\off 
features
- Hide implementation details, so that we can easily evolve the library 

A good way to start on this is to refactor the Swing uses of Synoptic into a 
library that can be reused from GWT.

Original issue reported on code.google.com by bestchai on 5 May 2011 at 12:11

[GoogleCodeExporter]

An important concrete issue that is relevant to this is to encapsulate 
refinement and coarsening state in the Synoptic core, instead of having the 
library clients maintain it.

Original comment by bestchai on 17 Dec 2011 at 3:42

[ohmann]

I'm currently working on this, but the target use case for Synoptic as a library has shifted since this issue's inception 4.5 years ago. :)

The goal described above of allowing manipulation of individual parts of the model inference process--e.g., refinement and coarsening--is not something I'm addressing now. This could be split into another issue if it's still desired. However, the overarching goal of allowing other applications to use Synoptic as a black box remains.

The current vision for the Synoptic library is one where applications can call Synoptic directly, use the application's own desired event types (not just Strings), and receive the output graph in intuitive graph objects. This involves three major enhancements:

1. Provide a single-method entry point where the calling application can pass in all required information without relying on files for the log or regexes. Really, alleviate the need to have a log or regexes at all and allow the application to pass in the "parsed" traces directly, i.e., a list of traces, where a trace is a list of generic T objects provided by the calling application. Support more complex T types, where a pair of T objects might consider themselves equal if they're close enough based on a similarity metric, for example (but this would be done within T, not within Synoptic). This means Synoptic can no longer assume that all events within a partition are exactly the same type (previous true because types could only be Strings), requiring refactoring in many places. One complication is that lots of Synoptic relied on being able to directly retrieve/compare the single event type of a Partition, while the above description of T types means that each Partition can now contain events with similar but non-identical event types. This complicates Partition logic in general, invariants, model checking, and therefore refinement and coarsening.
2. Return simple, intuitive graph objects as opposed to any of the current outputs, which are all plaintext graph formats. Essentially, the application calls Synoptic's entry method with its traces and is returned something like a SynGraph of SynNodes and SynEdges. The current idea is to make a set of interfaces for these objects so that Synoptic knows how to populate them but then allow the calling application to implement these interfaces. This means if the caller has specific graph objects it already uses, they can simply implement a few methods for Synoptic's SynGraph (and the others), and Synoptic's will return an inferred model already in the caller's preferred graph data structures.
3. The changes in (1) above require a reasonable amount of refactoring, and handling non-identical T types that are considered equal requires some of Synoptic's inner algorithms to be less efficient. Therefore, ensure that if event types are just Strings (as previously was always the case), the old and efficient methods are still used.