On Mon, Oct 12, 2009 at 17:57, Asiri Rathnayake <[email protected]> wrote: > Hi, > > > Here is some quick review comments: >> General: >> * this API is not streaming oriented, WikiImporter.import should take >> listener and not send a full Wiki for example. This api is nice but as >> a wrapper for the streaming api (like SAX and DOM or XWiki rednering >> events and XDOM). >> > > I kind of had a different idea about the streaming api. I don't know why I > thought this but what I had in mind was something like: > > Wiki::hasNextPage():boolean > > Wiki::getNextPage():WikiPage > > This is kind of like reading a result set (pull-parsing???) > > I thought this kind of a api would be more natural but I have no idea if > this is even possible to implement for all the wiki export formats out > there. > > If I understood you correct, what you have suggested is something like: > > WikiImporterListener::onWikiPage(WikiPage)
Not sure yet for the details but that's the idea yes. > > WikiImporter::import(......, WikiImporterListener) > > This might be viewed as a "push-parsing" mechanism?? Anyway, I'll be glad to > know what are the pros & cons of these two approaches. 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. > > >> *** [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
