On Wed, Oct 14, 2009 at 17:11, 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 ?
>
>>
>> -How to handle revisions - Can we have methods to read those tags too. one
>> for WikiPageRevision and other for AttachmentRevision.
Maybe something like:
beginWikiPage()
beginWikiPageRevision()
beginObject(type)
onProperty()
endObject()
beginObject()
onProperty()
endObject()
beginClass()
onProperty()
endClass()
beginAttachment()
onAttachmentRevision()
endAttachment()
endWikiPage()
beginWikiPageRevision()
beginObject(type)
onProperty()
endObject()
beginObject()
onProperty()
endObject()
onAttachmentRevision() (since i think you can't have several
attachement revision for the same wiki page revision)
endWikiPage()
endWikiPage()
basically you can look at XWiki xml ecport format and map something
similar for events I think (not the exact same thing the export format
need improvements).
>>
>>
>>> 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
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
