[ 
https://issues.apache.org/jira/browse/TIKA-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832817#comment-17832817
 ] 

ASF GitHub Bot commented on TIKA-4181:
--------------------------------------

bartek commented on code in PR #1702:
URL: https://github.com/apache/tika/pull/1702#discussion_r1546232766


##########
tika-pipes/tika-grpc/src/main/proto/tika.proto:
##########
@@ -0,0 +1,92 @@
+// Copyright 2015 The gRPC Authors
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+syntax = "proto3";
+package tika;
+
+option java_multiple_files = true;
+option java_package = "org.apache.tika";
+option java_outer_classname = "TikaProto";
+option objc_class_prefix = "HLW";
+
+
+service Tika   {
+  rpc CreateFetcher(CreateFetcherRequest) returns (CreateFetcherReply) {}

Review 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.



##########
tika-pipes/tika-grpc/src/main/proto/tika.proto:
##########
@@ -0,0 +1,92 @@
+// Copyright 2015 The gRPC Authors
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+syntax = "proto3";
+package tika;
+
+option java_multiple_files = true;
+option java_package = "org.apache.tika";
+option java_outer_classname = "TikaProto";
+option objc_class_prefix = "HLW";
+
+
+service Tika   {
+  rpc CreateFetcher(CreateFetcherRequest) returns (CreateFetcherReply) {}
+  rpc UpdateFetcher(UpdateFetcherRequest) returns (UpdateFetcherReply) {}
+  rpc GetFetcher(GetFetcherRequest) returns (GetFetcherReply) {}

Review Comment:
   Similar to above regarding documentation, it would be great to understand 
what happens if I try to get a fetcher which does not exist. Is there a 
distinct error, or do I simply get an empty GetFetcherReply?





> Grpc + Tika Pipes - pipe iterator and emitter
> ---------------------------------------------
>
>                 Key: TIKA-4181
>                 URL: https://issues.apache.org/jira/browse/TIKA-4181
>             Project: Tika
>          Issue Type: New Feature
>          Components: tika-pipes
>            Reporter: Nicholas DiPiazza
>            Priority: Major
>         Attachments: image-2024-02-06-07-54-50-116.png
>
>
> Add full tika-pipes support of grpc
>  * pipe iterator
>  * fetcher
>  * emitter
> Requires we create a service contract that specifies the inputs we require 
> from each method.
> Then we will need to implement the different components with a grpc client 
> generated using the contract.
> This would enable developers to run tika-pipes as a persistently running 
> daemon instead of just a single batch app, because it can continue to stream 
> out more inputs.
> !image-2024-02-06-07-54-50-116.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to