[Libreoffice] web based libre office
gedw99 at gmail.com
Mon Jan 24 08:17:32 PST 2011
On 24 January 2011 16:03, Michael Meeks <michael.meeks at novell.com> wrote:
> Hi Ged,
> On Mon, 2011-01-24 at 15:06 +0100, Ged Wed wrote:
>> whats the support for doing a web based open office ?
>> Ajax based with a restful JSON or XML model.
> Well, it is not an impossibly bad idea :-)
>> I am asking because this seems like such a good move.
>> Libre Office would then have a very compelling solution that neither
>> google Docs or MS Office can really compete against.
> Riight; except they are already in the market place - which makes us at
> least two years away from there, even if we had a product now :-)
well you gotta start sometime and technology is on our side.
- html5 browsers now everywhere. No IE hacks assuming no support for
anythign less than IE9
- The web frameworeks are so good now. checkout "argularjs"
- The single thread issue to the Open Office server is easily solved
using a NodeJS proxy.
>> - what is important is that both the fat client and the thin client
>> are both adapted towards the client / server model together. This
>> makes both version easy to maintain, change control, testing etc
> Well - since we have a fat client; I would personally focus on two
> a) feature parity between fat and web client
> + no-one else does this.
> + fat client for off-line, web for (who? ;-)
> b) abandon hope of off-line web editing: that's why you have the
> fat client right ? :-)
Well with AngularJS you could deliver the XML version of the document
and the angular JS name tags would then perform the required
composition to pure html. It would also round trip both ways and do
real time binding across the network.
Pretty easy solution and ready to go now.
But it means that all the logic in Open Office is thrown away because
we are talking directly to the file format.
Off line editing. No issue at all because as i explained your reading
and writing directly of the file format.
The actual files can be held offline using simple html5 storage APIs,
and synced back to a webdav server as and when required.
NodeJS has this functionality already on the server and client.
> which means, we have to re-use the fat client on the web server; that
> means all sorts of good things: we need to make it smaller, more
> reliable, faster to start, etc. etc.
> and it also makes some things a lot easier; IMHO doing remote rendering
> by cutting at VCL and proxying rendering (wherever possible) to a remote
> canvas, -might- work in semi-linear time.
> I'm thinking a re-hash of:
> Though of course VCL's rendering APIs are (now) substantially less
> pleasant than gtk+'s.
I saw this a while ago and yes it is a rehash, but not really.
As i write this i realise that html is so powerful now that its better
I really think that once you understand what angularJS is and how easy
it is to extend it and do it in a manageable way its pretty smart way
I know that this is controversial too and its a sever branch.
> michael.meeks at novell.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice