On Wed, Oct 14, 2009 at 17:22, Arun Reddy <[email protected]> wrote: > On Wed, Oct 14, 2009 at 8:41 PM, Thomas Mortagne > <[email protected]>wrote: > >> On Wed, Oct 14, 2009 at 17:03, Arun Reddy <[email protected]> wrote: >> > 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. >> >> If you plan to have something like >> >> beginWikiPage(name) >> beginObject(type) >> onProperty(name, value, ...) >> endObject() >> beginObject() >> onProperty() >> endObject() >> beginAttachment(name) >> endAttachment() >> endWikiPage() >> >> +1 it's a good idea, now i'm not sure why you need begin and end for >> an attachment, what other events would you have inside it ? >> >> > Because even it has few properties and revisions. > Kindly correct me, if am wrong.
You don't need an event for each property, event are more for variables things, you can have onAttachment(name, version, content, etc.). For revisions i already anwser in the previous mail, if you put the onAttachement inside a begin/endWikiPageRevision you will only have one version of the attachement for a version of wiki page. > >> > >> > -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 >> > >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
