Exposing information for administration purposes

We have initially considered a call to return a list of streams. Returning a full list of streams could be problematics if we have a very large list of streams. One way to narrow down is to refine it per scope, but even that could lead to a long list of streams.

Here are a few calls that seem to make sense from an admin perspective, and that would still enable the UI to know all streams if needed, but without having all of them returned in a single call.

listScopes() listStreams(scope) getNumberOfStreams(scope) getVolumeOfData(scope) getVolumeOfData getTotalNumberOfStreams getStreams(regex)

cc/ @bayarsaikhan

[jiazhai]

@fpj , The first stage of Metric is provide the fundamental interface and supporting of Metrics, so developer could use it to add anything they want, and of cause Counter is included. Currently only add some example of using it in host side code. Thanks.

[sggraham32]

What is driving the inconsistency between the REST API and the RPC? Any reason they cannot be the same set of operations?

Sent from my iPad

On Dec 19, 2016, at 3:28 PM, Bayar Volodya [e-mail] wrote:

Just copying status here so everyone can see. via @bhargav-gulavani @fpj

Calls useful for the UI, which we can expose via REST CreateStream, UpdateStreamConfig, GetStreamConfig, ListStreamsInScope, ListScopes

Internal calls exposed via RPC only GetLatestSegments, GetPositionAtTimestamp, GetNextPosition, GetURIForSegment, CreateTx, CommitTx, DropTx, GetTxStatus. Additionally CreateStream, UpdateStreamConfig, GetStreamConfig can also be exposed via RPC.

Assuming that the metrics data shall be served separately to UI, perhaps via statsD, and keeping consumer groups APIs aside for now.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.