Hi Vyacheslav,
Your example is actually the exception. When you create a type you can
add extension data to almost every levels of the type definition and it
will be transferred to the server. That is supported by all bindings.
But this has nothing to do extensions you find in the method signatures.
The ExtensionData is only defined and only works for the Web Services
binding. The AtomPub binding and the Browser binding rely on the Atom
and HTTP extension mechanisms. For example, to create a folder with the
Browser Binding the client sends URL encoded form data. The CMIS spec
allows to add extra data (key-value pairs) to it. So, protocol-wise that
is supported.
You can extract this extra data with the OpenCMIS server framework.
There is no obvious method, but it is possible.
On the OpenCMIS client side we don't have support for this. (We don't
have real support for ExtensionData, either). There weren't many
requests in the past to implement something like this.
If you have a good idea how to add this without polluting the interfaces
(for example duplicating all methods), let us know.
If you have the same data, that you want to send with all requests, have
a look the authentication provider. It allows you to set HTTP headers.
Not an elegant way, but it works with all bindings.
- Florian
Hi everyone,
I am trying to use pass some additional non-CMIS data from client to
server. For example, in case of creating a new type in the target ECM,
simple CMIS type definition may not be sufficient to pass all the
data. I was looking at using ExtensionsData since it is coming as an
input in almost every method on server side. But it seems that passing
ExtensionData is only supported by Web Services binding. The source
code on client for sending and on server for receiving does not do
anything for extension data. Sending extension data from server to
client seems to be supported by all bindings.
So my question: Is there a way to pass "extension data" without
resorting to Web Services binding?
I understand HTTP GET for Browser and AtomPub applies some
restrictions on sending data, but HTTP POST and PUT could include such
data. PUT & GET would suffice for a lot of scenarios while GET could
return extension data all the time if needed.
Regards,
Vyacheslav Pascarel
