On Mon, Oct 12, 2009 at 08:48, Arun Reddy <[email protected]> wrote: > Hi Devs, > > As the existing Wiki Importer ( GSOC PROJECT - SANDBOX > <http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/importexport/>) have > few set backs in architecture, i would like to make a proposal to > modify and enhance to make it better.
Great ! > > Here is my proposal : > > http://gsoc.myxwiki.org/xwiki/bin/view/Import+Export+other+wikis/Wiki+Importer+Enhancement > > - A new Wiki model api ( Wiki, Wiki Page, Wiki Page Revision, Wiki > Attachment ) which adheres to XWiki Standards. > > - Separation of Import process, Parsing the import data into a abstract wiki > model will be a component. Clients can use it to make their own custom > implementation. This abstract model is used by the other XWiki component / > client code (Groovy & velocity ) to load the data into XWiki with standard > features and little customization (like Preserving history, default names, > attachments etc.. ). +1 Always good to separate as much as possible every aspect of the process in different components. > > > - Using the existing XWiki model api or xwiki-bridge rather than coming up > with a new one. > But the issues here is, i dont have all the things which are needed and it > has lot more methods which are of no use in import process. Can i proceed > with a custom wiki model like this. ? Main problem is that you need a XDOM based model instead of a String content based model right ? The current model will definitely don't fit this, too bad the new model is not advanced enough. Also the current model is too linked to the storage so it will not be easy to do a clean stream based process. I would say do you own clean custom model and we will see latter for refactor with the new model. > > > - As wiki importer process large streams of data, would it be wise to design > the API more stream oriented and include few stream oriented methods.? Big +1 for stream oriented, the "normal" importer should be stream based also IMO. Denis Gervalle is currently working on making the whole export process and its dependencies stream oriented (See http://markmail.org/message/vzfdkteguzselouy). It's definitely the way to go. We can always to a wrapper api which is using the stream based api if we need a not stream based tools but the other way around is not possible so better to do now the more generic one. > > > I would like to have your suggestions on this. > > > Thanks > -Arun Reddy > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
