Hi, On Mon, Oct 12, 2009 at 10:27 PM, Asiri Rathnayake < [email protected]> wrote:
> Hi, > > Actually in my mind there was more than just this method, i see at least > > also > > > > WikiImporterListener::onWikiPageAttachment(AttachmentName, InputStream) > > > > since having the whole WikiPage with all its attachments in memory > > make the import not strong enough if you have too big attachments. > > Making a streaming API is about making every memory consuming part > > streamed (Actually to be sure maybe also have > > WikiImporterListener::onWikiPageObject(WikiPageObject) but since XWiki > > does not support this well internally currently it's less important > > than attachments). > > > > The getNextPage() API is good when you have only one simple kind of > > data in a plane list but the events based way is more generic and > > easier to implements for the importer writer IMO since it send the > > events when he wants. > > > > Ok, Now I understand that importer writers work would be easy if we go with > an event based API. > > So for Arun this means, > > 1. The model you proposed is ok > > 2. You need to refine the WikiImporter API so that it takes into account > what we discussed here. This means: > > i) Have a mechanism for defining WikiImporter components with different > requirements (look at the getParameters() approach suggested by Thomas) > > ii) Make the WikiImporter api mode stream oriented. I think you can start > with onWikiPage() & onAttachment() events for now. > > - Can we have beginWikiPage() followed by endWikiPage() beginAttachment() and endAttachment() rather than having a single onWikiPage(),onAttachment() in the WikiImporterListener. -How to handle revisions - Can we have methods to read those tags too. one for WikiPageRevision and other for AttachmentRevision. > I think you should start working on a revised proposal with this > information > taken into account. In the mean time other developers will comment on this > proposal if they have further suggestions. > > - Asiri > > > > > > > > > > >> *** [NICE TO HAVE] List<Class<?>> getParameters(): the list of > > >> parameters type to provide to the importer, that way you can generate > > >> a UI based on it since parameters totally depends on the importer, you > > >> could have an importer able to import the wiki from an URL for example > > >> using REST/XMLRPC... for the same reason List<InputStream> is not > > >> generic enough IMO. You can look at MacroDescriptor for inspiration, > > >> we could make it more generic as a list of parameters instead of a > > >> list of macro parameters to use it in wiki importer, authenticators, > > >> etc. I see this tool as a generic way to get wiki content from any > > >> kind of external source, we could even use it to copy a XWiki wiki > > >> without having to do an export/import by hand for example. > > >> > > > > > > +1 > > > > > > This will make it possible to define different types of importers with > > > different requirements (rather than restricting them to > > List<InputStream>) > > > > > > Thanks. > > > > > > - Asiri > > > _______________________________________________ > > > 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 > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Best Regards, Arun Reddy _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
