We are migrating CKEditor issue tracking to GitHub. Please, use GitHub to report any new issues.

The former tracking system (this website) will still be available in the read-only mode. All issues reported in the past will still be available publicly and can be referenced.

Important: we decided not to transfer all the tickets to GitHub, as many of them are not reproducible anymore or simply no longer requested by the community. If the issue you are interested in, can be still reproduced in the latest version of CKEditor, feel free to report it again on GitHub. At the same time please note that issues reported on this website are still taken into consideration when picking up candidates for next milestones.

Implement Interface for File Browser Connector and Quick Uploader

Description

I would like to make the File Browser Connector and Quick Uploader configurable with a Java interface. The current implementation is hardcoded to use the server file system. This is something which severly limits the use of the Java libary in more mature products or frameworks, because it's likley that these do have their own way of managing the server side resources - not necessarily on the server file system.

Now the extensibility of it
is built into the XML interface, so if someone wants to do something
different he should also implement the XML parsing and the building of
the response. A better approach would be allowing a plug-in-like
extensibility, where the official connector is the one responsible for
the request and response management, and then calls another library to
do the real work. So if you want to use the file system based
repository you can use the default implementation, but if you want to
change the behavior, and use a per user folder, or retrieve files from
an FTP storage or from a DB you can do it just implementing an
interface and implementing the methods important for the real file
retrieval and storage.

This has been implemented to some extent with the interface ​SessionData. Additionally there will be some method to upload to a server path which is served by a different server but there is no way that we break the context sandbox concept with upload to a different context or to some random path which is will serve by ia proxy filter by upload a byte stream.

This has been implemented to some extent with the interface ​SessionData. Additionally there will be some method to upload to a server path which is served by a different server but there is no way that we break the context sandbox concept with upload to a different context or to some random path which is will serve by ia proxy filter by upload a byte stream.

IMHO that is not the meaning of this feature request! The need is to provide an abstract way to implement other connectors than the current one for the filesystem. SessionData doesn't provide that feature !!!
That feature could implemented in future releases!