On Mon, 19 May 2014, Sergey Beryozkin wrote:
I've just looked at the source, unfortunately adding a new Path value will
affect the request URIs, UnpackerResource has 2 methods accepting path
segments starting from "/unpacker" and "/all".
So if we updated then the users would have to modify URIs to contain
"/unpack/unpacker1", etc, as opposed to the current "unpacker1".
I think it might be good to push them into a common path prefix.
Though /unpack/unpacker seems a bit unwieldy...
If it only had 1 resource method then we'd just push that method's Path up
and update the method's Path to "/", but it has 2 methods.
I suppose worst case we could create an abstract parent, put most of the
logic there, then have two classes one per method?
I'm not sure how used is UnpackerResource. If no one uses it or very few
users use it then may be it is the right time to introduce a class-level
Path and document the possible migration task.
Maybe we should post to users@, and see if anyone says they do?
Thanks
Nick
