Hi all,
With the ongoing encoding revamp work on Infinispan, time to decide how to handle the rest server.
The rest server currently stores along with each entry, a string representing the MimeType of that entry, which allows the user to POST/PUT each entry with its own format.
At request time, using the accept header, the user can request the entry in a particular format, and the rest server internally extracts the mime type from the entry and converts it accordingly.
The issue with this approach is, apart from the extra space required, it makes it challenging to expose via rest anything less trivial than put/get. Think for example querying, consistent hash calculations, stream operations: all those features will have a hard time dealing with a cache where each entry has a different format.
+1. When I was refactoring REST interface it seemed a little bit strange to me that we perform this type of conversion. I'm all for removing it and simplifying the code.
Remove this behavior completely. For a certain cache, all entries will be homogeneous, just like
Hot Rod, Memcached and embedded. The user can optionally configure the MimeType at cache level.
Impacts:
- It may be required for users to add the media type configuration to the cache, if supporting
multiple formats is required;
Sounds good to me. I'm just curious, what would happen if a cache is configured to store Strings and I will POST binary content? Will I get HTTP 4XX?
- Migrating from 9.1 to 9.2 may require re-populating the cache if multiple formats are being used;
I think this should be a part of a Remote Cache Store. This way we will support it from Rolling Upgrade perspective.
- From the API perspective, I don't expect any change: POST/PUT with multiple formats should be still supported, as the internal transcoding should convert them on the fly to the unified configured format.
Thoughts?
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
