Lyra api #191

Closed
wants to merge 10 commits into
from

Conversation

Projects
None yet
3 participants
@waxlamp
Contributor

waxlamp commented Jul 15, 2014

Some proposed additions/changes to allow for Lyra to be used in "editor mode".

signalwerk and others added some commits Mar 1, 2014

@waxlamp

This comment has been minimized.

Show comment
Hide comment
@waxlamp

waxlamp Jul 15, 2014

Contributor

A related but separate problem: how to treat data going back and forth between an editor app and Lyra.

  1. The vision is to, e.g., send a small subset of the full data to editor-mode Lyra, design a visualization, and then "plug in" the full data when the visualization comes back. What are the semantics of working this way? What guarantees should the user have about data suddenly changing under them while making use of a Vega/Lyra spec?
  2. Vega specs can now have their data URL point to a, e.g., Tangelo data service that returns the newest available results. Can we have an "autorefreshing" Vega spec that asks for data from its URL every 10 seconds, etc.?
  3. We may want to think about how to handle the "big data" problem at some point. It's not enough to supply a URL in place of the data, because either way we will end up trying to hold all the data on the clientside anyway. Is there a generalized model of Vega's data attribute that can stream data from the server in smaller chunks?
Contributor

waxlamp commented Jul 15, 2014

A related but separate problem: how to treat data going back and forth between an editor app and Lyra.

  1. The vision is to, e.g., send a small subset of the full data to editor-mode Lyra, design a visualization, and then "plug in" the full data when the visualization comes back. What are the semantics of working this way? What guarantees should the user have about data suddenly changing under them while making use of a Vega/Lyra spec?
  2. Vega specs can now have their data URL point to a, e.g., Tangelo data service that returns the newest available results. Can we have an "autorefreshing" Vega spec that asks for data from its URL every 10 seconds, etc.?
  3. We may want to think about how to handle the "big data" problem at some point. It's not enough to supply a URL in place of the data, because either way we will end up trying to hold all the data on the clientside anyway. Is there a generalized model of Vega's data attribute that can stream data from the server in smaller chunks?

arvind added a commit that referenced this pull request Jul 16, 2014

@arvind

This comment has been minimized.

Show comment
Hide comment
@arvind

arvind Jul 16, 2014

Member

Ok, Lyra beta is now message-aware to enable an "editor mode" (ba75ddc). You can post a message to Lyra in this format {timeline: {}, data: {name: '', values: []}}. timeline is optional. If no timeline is specified, Lyra will load the dataset, and assign it as the source for the default Pipeline 1. When in editor mode, we hide the open and save buttons at the bottom, and instead offer an "export back" button, which will post the timeline and spec ({timeline: {}, spec: {}}) back to the original application. For now, the spec will feature inlined data values, pending #192.

Member

arvind commented Jul 16, 2014

Ok, Lyra beta is now message-aware to enable an "editor mode" (ba75ddc). You can post a message to Lyra in this format {timeline: {}, data: {name: '', values: []}}. timeline is optional. If no timeline is specified, Lyra will load the dataset, and assign it as the source for the default Pipeline 1. When in editor mode, we hide the open and save buttons at the bottom, and instead offer an "export back" button, which will post the timeline and spec ({timeline: {}, spec: {}}) back to the original application. For now, the spec will feature inlined data values, pending #192.

@arvind arvind closed this Jul 16, 2014

@arvind arvind referenced this pull request in vega/polestar Jan 4, 2015

Closed

Export to lyra #7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment