On 24 January 2011 16:03, Michael Meeks <michael.meeks@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
things:
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:
http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/
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
to just forget the past and do it all in html and JavaScript.
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
forward.
I know that this is controversial too and its a sever branch.
HTH,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
Gerard
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.