chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damian Sima <damians...@gmail.com>
Subject Re: CMIS Bridge
Date Fri, 11 May 2012 11:50:00 GMT
That's brilliant I've been trying myself to create something like that I'll
be happy to take a look at it when you guys release it.

+1

On 11 May 2012 07:38, Florian Müller <fmui@apache.org> wrote:

> Hi all,
>
> We have built something that we would like to contribute to OpenCMIS. We
> have called it the CMIS Bridge.
>
> The CMIS Bridge acts like a proxy between a CMIS client and a CMIS
> repository. This proxy can intercept CMIS requests and manipulate the data
> that goes in and out.
>
> Here are a few use cases for the CMIS Bridge:
> - Binding changes. For example, a repository with a broken Web Services
> binding implementation can use the bridge to accept Web Services calls and
> turn them into AtomPub calls. And vice versa, of course.
> - Repositories that don't implement the browser binding yet can use it as
> a quick way to provide the browser binding.
> - The bridge can also host a web application that uses the browser binding
> without the hassle of dealing with the same-origin policy in web browsers.
> - It can be used as a repository filter. It may only allow access to a few
> but not all repositories that a server exposes.
> - The bridge may handle authentication mechanisms that the target
> repository cannot handle. The combination of the browser binding and OAuth
> comes to mind.
> - Objects and properties can be hidden and virtual objects and properties
> can be added on the fly.
> - Objects can be enriched on the fly. For example, when a client uploads a
> MP3 file the bridge can extract the MP3 metadata and adds them before the
> object is created on the target repository.
> - Folder structures and templates can be created on the fly.
> - It can be used in protect a repository. For example, the repository
> could run behind a firewall and the bridge resides in the DMZ.
>
> There are probably many more use cases.
>
>
> The current implementation is quite basic. It works, but there is a lot of
> room for improvement and optimization. This is something we want to do over
> the next weeks and months.
>
> Are there any objections to add this to OpenCMIS?
>
>
> Thanks,
>
> Florian
>
>


-- 
Damián. > - )

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message