Re: External Data providersin Calc - GSoC project

Hello Vikas,

On Tue, May 15, 2018 at 11:13 AM, Vikas Mahato <vikasmahato0@gmail.com>
wrote:

> Hi all,
>
> I looked into how to make UNO components for calc and referred to
> Solver.idl and XSolver.idl in  offapi module for more understanding.
>
> I am thinking of moving the existing implementation of dataproviders and
> datatransformations (located at sc/source/ui/dataproviders) to two UNO
> components.

Please don't. The internal ones are the canonical data providers and I
would like to keep them as it is much easier to design APIs and debug
general problems through internal API code. The UNO API will allow
extensions to add additional data providers and data transformations. In
the end you will notice that you will map some of the UNO API code to
internal code anyway and your internal code will help you shape the API.


> This would mean creating 4 new files in offapi/com/sun/star/sheet namely
>
> ExternalDataProvider.idl
> XExternalDataProvider.idl
> DataTransformations.idl
> XDataTransformations.idl

That sounds about right.


> ExternalDataProvider will host the following methods:
> 1. void Import()
> 2. OUString& GetURL()
> 3. map<OUString, OUString> getDataSourcesForURL(const OUString& rURL)
> 4. unique_ptr<SvStream> FetchStreamFromURL(const OUString&,
> OStringBuffer& rBuffer)


Note that in UNO API we can not use most of the C++ classes. unique_ptr
needs no equivalent anyway as all UNO API objects are reference counted
(uno::Reference, rtl::Reference). Finding a good replacement for
map<OUString, OUString> will be more challenging and might require using
something along the lines of uno::Sequence<some string pair type>.

I'm not sure if we need the Import function in the API. Keep in mind that
the importing is completely handled by the internal code and should not be
started by an extension. I suppose it will be enough for the actual uno
object implementation to have an object which provides all the necessary
methods.


> DataTransformation will host all the methods defined in
> datatransformation.hxx
>
> I want to convert the existing implementations to UNO so that external
> application developers can make use of the functionality as well.

As mentioned, we should have the UNO API as layer on top of the internal
API. At least in Calc (and Charts) we have made bad experiences in the past
with pure UNO API features.

Regards,
Markus

> Looking for suggestions and feedback.
>
> Kind Regards,
> Vikas Mahato
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice