It looks like LibreOffice was formerly Apache OpenOffice but probably a lot of the code is still the same. Apparently OpenOffice was built on something called UNO, Universal Network Objects.
There is a developer guide to OpenOffice . It describes UNO and how to use it.
There is a forum for OpenOffice that probably is also relevant for LibreOffice.
There is a forum for LibreOffice too so I guess you have to check both.
Probably a Universal Content Provider for Solid pods needs to be written.
Also, In the developer guide under the heading of Database Access, it says:
The goal of the OpenOffice.org API database integration is to provide platform independent database connectivity for OpenOffice.org API. While it is necessary to access database abstraction layers, such as JDBC and ODBC, it is also desirable to have direct access to arbitrary data sources, if required.
The OpenOffice.org API database integration reaches this goal through an abstraction above the abstractions with the Star Database Connectivity (SDBC). SDBC accesses data through SDBC drivers. Each SDBC driver knows how to get data from a particular source. Some drivers handle files themselves, others use a standard driver model, or existing drivers to retrieve data. The concept makes it possible to integrate database connectivity for MAPI address books, LDAP directories and OpenOffice.org Calc into the current version of OpenOffice.org API.
Since SDBC drivers are UNO components, it is possible to write drivers for data sources and thus extend the database connectivity of OpenOffice.org API.
I am only auditing this course and not taking it for credit, because my major is home economics :
I didn’t know about Unhosted, thanks! I see your name at https://wiki.p2pfoundation.net/Unhosted . I’ll read and try to figure it out.
Anyway, if you or anybody think(s) LO on Solid is unnecessary or a bad idea please let me know. It looks like LO understands mostly relational so I’m not sure how to translate from RDF to RDBMS on the fly or how it can be done so the reverse can restore the original, or if its possible to not translate RDF at all and still have it be useful in LO.
I guess LO’s databases could just be kept in the pod as they are, in SQL. That would at least get things moving until it’s clearer how RDF can work in LO.
I’m not knowledgeable about LibreOffice but I think this is the product that we need to build on Solid - it is code for a cloud-based online collaboration minus the file system integration, which,. of course, should be via Solid.
Yes, you’re right I think.
But I noticed this further down:
The Document Foundation suggests that all large-scale deployers of LibreOffice use certified developers either directly or via a commercial provider who employs them. This is especially important for LibreOffice Online where your business plays an important role paying for the further development of the software.
Please do not attempt a public or enterprise production deployment of LibreOffice Online without professional support. As explained above, it is not intended for direct production deployment.
The only certification I have is my AARP card.
I’ve been using LibreOffice first on Windows and then on Linux for several years now, just for simple documents and spreadsheets. It is good enough for most users, though some tough edges and possibly not everything needed for power users. I used OpenOffice (I think) until it sounds of into LibreOffice as a result of Oracle b doing something (making it closed?).
So I think it is a good option to look into for Solid.
Probably someone at Inrupt should talk to someone at TDF or Collabora or the Cambridge Network about LibreOffice Online. I saw somewhere that LO has 200 million users.