Re: Asynchronous use of SwHTMLParser - is this needed

On 20/04/12 09:01, Miklos Vajna wrote:
> On Thu, Apr 19, 2012 at 05:06:43PM -0400, Kohei Yoshida <kohei.yoshida@gmail.com> wrote:
> > My question is, do we need to keep this asynchronicity of
> > SwHTMLParser, or is it okay to change it into a synchronous call like
> > the rest of SvParser uses?
>
> I would be surprised if this would be really required, all the sw
> filters I know of are synchronous ones.

then you haven't heard of these ones:

> filter/source/config/fragments/filters/HTML.xcu:        <prop oor:name="Flags"><value>IMPORT 
> EXPORT ASYNCHRON PREFERRED</value></prop>
> filter/source/config/fragments/filters/HTML__StarWriter_.xcu:        <prop 
> oor:name="Flags"><value>IMPORT EXPORT ALIEN ASYNCHRON</value></prop>
> filter/source/config/fragments/filters/writer_web_HTML_help.xcu:        <prop 
> oor:name="Flags"><value>IMPORT INTERNAL NOTINFILEDIALOG NOTINCHOOSER ASYNCHRON 
> READONLY</value></prop>
> filter/source/config/fragments/filters/writerglobal8_HTML.xcu:        <prop 
> oor:name="Flags"><value>EXPORT ALIEN ASYNCHRON NOTINCHOOSER</value></prop>

quite what the advantage of that is i don't know; presumably it makes
Writer a better Web browser somehow?

> > I'm working on removing SvRefBase from SvParser to make its life cycle
> > a little more easier to understand.  I've checked the call sites of
> > all of its derived classes, and in most of those call sites, we could
> > easily replace it with scoped_ptr.  The only exception is the
> > SwHTMLParser, where its use involves asynchronous call to parse HTML
> > input.  This makes a bit non-trivial to manage its life cycle.

would wrapping a shared_ptr around it work?