Felix Meschberger schrieb:
Hi all,
triggered by Paul Noden's JSON import support for the SlingPostServlet,
I have started to think about generalized support for import/export of
repository content. I imagine, that we would have single bundle, which
provides support for import and export of content and which is used by
the various players around this issue.
But before getting into the gory details of my idea, let me first list,
what we have today:
(1) Initial Content Loading
The initial content loader implemented in the jcr/contentloader bundle
is able to load (aka import) content from bundles into the repository in
a variety of formats: XML, JSON and JCR sysview XML. In addition it
supports (or will support) flags for tuning the import like what to do
on overwrite and what to do with versionable nodes.
The format support is currently hardcoded and only extensible by
extending the bundle itself. Yet, there have been discussions on making
this support extensible.
(2) Default Get Servlet
Export in JSON format is supported in the default GET Servlet. In
addition support for JCR sysview XML (or generic XML) has been asked for
in SLING-393.
(3) SlingPostServlet
The SlingPostServlet supports kind of a content import by supporting
node creation/modification through HTTP requests. In addition, Paul is
working on supporting JSON formatted import, where the JSON format is
the one created by the default GET Servlet export (and also supported by
the initial content loading).
Again here, discussion already took place to not only support JSON but
also other formats, most notably JCR sysview XML.
Problem
-------
These mechanisms are all very functional but lack proper extensibiliyt
and most notable, the import and export code bases are split. For
example JSON generation is implemented in the default GET Servlet and
depends on yet other code from the commons/json bundle. Import code on
the other hand is prominently implemented in the Initial Content Loading
bundle and will probably be re-used in some form in the
SlingPostServlet.
Solution
--------
We create an import/export bundle, which is extensible by providing a
Service interface for specific format support:
public interface ImportExportHandler {
// return list of MIME content types supported by this
String[] getMimeTypes();
// return list of file extensions supported by this
String[] getExtensions();
// import content
// @throws UnsupportedOperationException if import not
supported
??? import(???)
// export content
// @throws UnsupportedOperationException if export not
supported
??? export(???)
}
I do not know yet the exact API for the import and export methods, which
is why I placed "???" there. I was thinking of using an intermediary
format for the import and direct repository access for the export. Maybe
it would be like getting an InputStream on import and an OutputStream on
export in addition to the session to access the repository, sort of
like:
void import(InputStream source, Session session, Map<String, Object>
flags);
void export(OutputStream dest, Session session, Map<String, Object>
flags);
where the flags would contain more settings for the import/exports like
the start node, export depth, content overwrite, initial-checkin-status,
etc. Maybe the flags is not appropriate and explicit (and finite)
parameters are better ?
To access the generalized import/export functionality an
ImportExportService is defined, which provides access to import/export
handlers and supports utility functions:
public interface ImportExportService {
// return a handler by mime type or null if none
ImportExportHandler getHandlerByMimeType(String mimetype;
// return a handler by file name (extension) or null if none
ImportExportHandler getByFileName(String fileName);
// import from a source with default setting selecting the
// handler by MIME type or file name extension
// @throws UnsupportedOperationException if a handler exists
// for the type but the handler does not support import
// @throws IllegalArgumentException if no handler for the
type
// is registered
void import(InputStream source, String type);
// export to a stream with default setting selecting the
// handler by MIME type or file name extension
// @throws UnsupportedOperationException if a handler exists
// for the type but the handler does not support export
// @throws IllegalArgumentException if no handler for the
type
// is registered
void export(OutputStream destination, String type);
}
Formatproviders would implement the ImportExportHandler interface. Users
of the functionality such as the default GET servlet, the
SlingPostServlet and the Initial Content Loader would use the
ImportExportService for their tasks.
This feature can well be implemented after a first release because it
only touches implementation of current functionality.
WDYT ?
Sounds good to me; I guess we have to experiment a little bit with the
interface
during development to see what's best.
I think we should postpone this until after the release.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
