Deephaven Extensions #1468

My general opinion is that you need something like three examples to generalize something like this. Of our other exported types, ignoring changing values in the export itself, a Figure seems to be a good second example, but I would encourage trying to find a third that also maps well to this idea.

Figures would offer a possible answer for the ticking data part of the question - when a figure is exported, it also provides tickets for other objects, such as Tables and TableMaps. If the getDeephavenObject method returned not just base64 data of the object itself, but also an array of other tickets (and presumably the index in that array would be referenced from in the base64 data), the client can decide how to subscribe to those tables, and get updates as necessary through either the TableService.exportedTableUpdates stream, or through individual subscription streams.

If the exported object itself can change over time (rather than re-export the entire thing), this might suggest that TableMap would be another good candidate to include in this model. The risk here is that TableMap might end up with some custom serialization mechanism (to handle SmartKeys), to handle its append-only updates. My hunch though is that unless these objects are gigantic, a delta would be easier to manage by resending the entire object, but I think more discussion around specific examples would make sense. If the changing part of the model can be made to fit into an associated Table (consider a Table in a TableMap that consists only of the keys), that would make for a straightforward way to pass the data.

--

One final note, base64 isn't strictly required by the transport mechanism - protobuf can support a bytes field, and we can optionally expose that to the JS UI as a typedarray of bytes, or a base64 string.

As another example that may fall under this category, I've wanted a widget that could be driven off of a Deephaven table. For example, I have a table that has a single column and single ticking row, representing percentage with a value in the range [0.0, 1.0]. I'd like the ability to view it as a half-circle speedometer and/or a temperature gauge.

x = compute_my_perc_table()
w1 = speedometer(x)
w2 = tempgauge(x)

These types of widgets may be driven server + client side; or completely client side (a layout that defines w1/w2 instead of having it done via server vars).

I'm more interested in drilling down into how we can extend the abstractions / serialization around ExportedObjectType before trying to imagine what it might look from a folder structure. (I have reservations with how we've set some stuff up in the past...)

Specifically, I think the goals are:

1. Support custom extensions without the need to change server code
2. Support "complex" custom type information, without sending the full data payload
3. Provide an easy method for installing / referencing extensions

Another thing to consider in terms of directory structure... we may want a startup script, and also a resource file that's available on the path. Is there a way to do that cleanly @devinrsmith ?
Just looking at matplotlib, you can pass your own stylesheet, but we'd need to have it somewhere on the path to pass it.