Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom fields in SeldonMessage #198

Closed
killwing opened this issue Aug 2, 2018 · 6 comments
Closed

Custom fields in SeldonMessage #198

killwing opened this issue Aug 2, 2018 · 6 comments

Comments

@killwing
Copy link

killwing commented Aug 2, 2018

The structure of SeldonMessage is not sufficient to carry custom parameters, sometimes we need both data and binData/strData.

message SeldonMessage {
  Status status = 1;
  Meta meta = 2;
  oneof data_oneof {
    DefaultData data = 3;
    bytes binData = 4;
    string strData = 5;
  }
}

Is it possible change to below ?

message SeldonMessage {
  Status status = 1;
  Meta meta = 2; 
  DefaultData data = 3;
  bytes binData = 4;
  string strData = 5;  
}
@ukclivecox
Copy link
Contributor

Certainly something we could consider but it would be a big change as all the API components and wrappers would need changing.

Can you explain your use case so we can understand it better.

Certainly the ability to send data both outside the standard default data and inside it makes sense.

@killwing
Copy link
Author

killwing commented Aug 2, 2018

Seems that seldon wrappers only support classification ?
Besides classification, we have more cases like object detection, feature extraction etc. that need some custom params.

@ukclivecox
Copy link
Contributor

The wrappers support a predict which a general array (numpy for python) and returns an array (numpy for python). The shape of those arrays are unrestricted except at present for the return array which needs to have dimension >= 2.

So the possibilities are wider than classification.

However, we should try to support custom string/byte data easily as well.

I think a easy addition for your original requirement would be to extend the proto bufs with new fields for extra byte and string.

@killwing
Copy link
Author

killwing commented Aug 2, 2018

We're trying to add new fields for now. thx.

@ukclivecox
Copy link
Contributor

I think adding new extra fields to the protobuf would mean the API can remain backwards compatible. If you could submit your changes as a Pull Request that would be great.

@ukclivecox
Copy link
Contributor

Please update if there is work that can be contributed back @killwing. Will close for now.

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

No branches or pull requests

2 participants