TIKA-4181 - Tika Pipes Grpc Server #1702
Conversation
| } | ||
|
|
||
| message CreateFetcherRequest { | ||
| string name = 1; |
There was a problem hiding this comment.
Must name be unique across all initialized fetchers? name to me implies it's a descriptive label, is this more of an ID?
Use case I am thinking of if I create multiple fetchers with the same class. Right now I would create a unique name for each one. Is that the correct expectation?
There was a problem hiding this comment.
yes we are using "name" as the ID. @tballison any thoughts here? maybe we should rename that for 3.x
|
|
||
|
|
||
| service Tika { | ||
| rpc CreateFetcher(CreateFetcherRequest) returns (CreateFetcherReply) {} |
There was a problem hiding this comment.
Could we document these RPCs to understand high level behaviour? For example, if I try to create a fetcher which already exists, what is the expected reply? Is it an error response on the RPC, will CreateFetchReply have error identifying information?
If CreateFetcher was made idempotent, could we collapse these into a single RPC (UpdateFetcher), which either creates, or updates, or noops (no changes despite call) to the Fetcher?
Don't want to over complicate the Tika side of course, but curious if we can improve the client interface.
add reflection api for grpc so you can use grpc curl
Add an Apache Tika GRPC Server