Discussion:
web based libre office
(too old to reply)
Ged Wed
2011-01-24 14:06:24 UTC
Permalink
Hey all,

whats the support for doing a web based open office ?
Ajax based with a restful JSON or XML model.

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.

It also allows "freedom Box" principles, because you can stick on it
on your home server and access it from anywhere.

As far as Architecture my high level ideas are:
1. Very chatty to the server. The idea is to do as little special code
for the web based version. So whatever ever calls the client currently
does we try to imitate that.
- 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

2. there are some amazing web frameworks with real time automatic binding etc.
AngularJS is probably the best one i can think of for a project like
this.. The binding mechanism is so elegant and simple.
- It also allows for collaboration using web sockets etc very easily
without allot of data mapping under the hood.

Of there is already a group of people etc that are driving towards
this type of objective please introduce me to you :)



Regards

Gerard Webb
Michael Meeks
2011-01-24 15:03:16 UTC
Permalink
Hi Ged,
Post by Ged Wed
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 :-)
Post by Ged Wed
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 :-)
Post by Ged Wed
- 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 ? :-)

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.

HTH,

Michael.
--
michael.meeks-Et1tbQHTxzrQT0dZR+***@public.gmane.org <><, Pseudo Engineer, itinerant idiot
Ged Wed
2011-01-24 16:17:32 UTC
Permalink
Post by Michael Meeks
Hi Ged,
Post by Ged Wed
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 :-)
Post by Ged Wed
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.
Post by Michael Meeks
Post by Ged Wed
- 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.
Post by Michael Meeks
       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.
       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.
Post by Michael Meeks
       HTH,
               Michael.
--
Gerard
Michael Meeks
2011-01-24 16:53:59 UTC
Permalink
Hi Ged,

So - thank you for your nice ideas :-) we can setup a list for this
discussion: crack-smoking-re-write-everyhing-in-javascript-ARL+***@public.gmane.org or
somesuch ? :-)
Post by Ged Wed
well you gotta start sometime and technology is on our side.
Technology is never on the side of people who don't learn from the
past. It is already hard enough to re-write an application based on a
known good base, that has the API set you want because it makes very
little business or technical sense. Incremental re-factoring, makes lots
of sense - but cannot tolerate huge, disruptive technology change.

The idea that we have to start sometime is not quite true ;-)
Post by Ged Wed
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.
Right - we made something easier (using this toolkit for editing), and
accidentally introduced the need to re-write several millions of lines
of code in a duct-tape inspired, type-unsafe language :-)
Post by Ged Wed
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.
Unfortunately, HTML is not sufficiently powerful that it writes the
code for you simply by reading your thoughts. Corel tried something at
least nominally achieveable - re-writing to use Java, and ... what
happened to that ? :-) Microsoft tried re-writing Office once in the
past which didn't turn out so well (they abandoned it after some huge
sunk cost).
Post by Ged Wed
I know that this is controversial too and its a sever branch.
Well - the good news is, that you can use OO.o for what you want now:
which sounds like file format conversion from <whatever> to the ODF that
your new javascript front-end will (no doubt) love to use.

Sadly - I think you will find the first 50%+ of the task is easy - and
you'll get a demo working fast. Then you'll discover that things like
layout, and spreadsheet computation is hard - and give up :-) Indeed,
instead of doing the 50% yourself, why not take something that works
already - eg. 'dojo' and then 'just' add a layout feature - like WYSIWYG
footnotes to experience the fun :-)

Either way - I don't think this discussion really belongs here - sorry.

All the best,

Michael.
--
michael.meeks-Et1tbQHTxzrQT0dZR+***@public.gmane.org <><, Pseudo Engineer, itinerant idiot
Jonathan Aquilina
2011-01-27 08:36:15 UTC
Permalink
Post by Michael Meeks
Hi Ged,
So - thank you for your nice ideas :-) we can setup a list for this
somesuch ? :-)
Post by Ged Wed
well you gotta start sometime and technology is on our side.
Technology is never on the side of people who don't learn from the
past. It is already hard enough to re-write an application based on a
known good base, that has the API set you want because it makes very
little business or technical sense. Incremental re-factoring, makes lots
of sense - but cannot tolerate huge, disruptive technology change.
The idea that we have to start sometime is not quite true ;-)
Post by Ged Wed
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.
Right - we made something easier (using this toolkit for editing), and
accidentally introduced the need to re-write several millions of lines
of code in a duct-tape inspired, type-unsafe language :-)
Post by Ged Wed
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.
Unfortunately, HTML is not sufficiently powerful that it writes the
code for you simply by reading your thoughts. Corel tried something at
least nominally achieveable - re-writing to use Java, and ... what
happened to that ? :-) Microsoft tried re-writing Office once in the
past which didn't turn out so well (they abandoned it after some huge
sunk cost).
Post by Ged Wed
I know that this is controversial too and its a sever branch.
which sounds like file format conversion from<whatever> to the ODF that
your new javascript front-end will (no doubt) love to use.
Sadly - I think you will find the first 50%+ of the task is easy - and
you'll get a demo working fast. Then you'll discover that things like
layout, and spreadsheet computation is hard - and give up :-) Indeed,
instead of doing the 50% yourself, why not take something that works
already - eg. 'dojo' and then 'just' add a layout feature - like WYSIWYG
footnotes to experience the fun :-)
Either way - I don't think this discussion really belongs here - sorry.
All the best,
Michael.
I wouldn't mind spear heading an effort to do a python port of LO in
regards to going web based. Cant you integrate the C++ code we have with
python?
Michael Meeks
2011-01-27 10:48:55 UTC
Permalink
Hi Jonathan,
Post by Jonathan Aquilina
Post by Michael Meeks
Either way - I don't think this discussion really
belongs here - sorry.
..
Post by Jonathan Aquilina
I wouldn't mind spear heading an effort to do a python port
of LO in regards to going web based. Cant you integrate the
C++ code we have with python?
If you want to do a python port of some things; I guess working on some
Java -> Python conversion would be great for some of the built-in
extensions etc.

I really think that a web based office suite is only possible in linear
time by doing something like the VCL / canvas cut that I suggested.

I would -very-strenuously- discourage people from trying to 'port'
-all- of LO from one language to another though ;-) not because it is
impossible (though it is nearly), but simply becuase we can do -much-
more useful and productive things for people.

So - again I would say this belongs on the crack-smoking list ;-)
though - IMHO writing a VCL <-> remote web/canvas renderer is worth
actually discussing here.

ATB,

Michael.
--
michael.meeks-Et1tbQHTxzrQT0dZR+***@public.gmane.org <><, Pseudo Engineer, itinerant idiot
Thorsten Guenther
2011-01-28 09:48:26 UTC
Permalink
Post by Michael Meeks
Post by Jonathan Aquilina
I wouldn't mind spear heading an effort to do a python port
of LO in regards to going web based. Cant you integrate the
C++ code we have with python?
If you want to do a python port of some things; I guess working on some
Java -> Python conversion would be great for some of the built-in
extensions etc.
Hi,
could you please give me an idea why it would be useful to replace a
language alien to the core with another alien? I guessed the replacement
of Java is to eliminate integration issues. If that's not the case...
whats the problem with Java? Just the "is a appropriate JRE / JDK
installed" issue?. Sorry, perhaps a noob question.

Thanks, regards
Thorsten Guenther
Michael Meeks
2011-01-28 10:17:25 UTC
Permalink
Hi Thorsten,
Post by Thorsten Guenther
Post by Michael Meeks
Post by Jonathan Aquilina
I wouldn't mind spear heading an effort to do a python port
of LO in regards to going web based. Cant you integrate the
C++ code we have with python?
If you want to do a python port of some things; I guess working on some
Java -> Python conversion would be great for some of the built-in
extensions etc.
..
Post by Thorsten Guenther
could you please give me an idea why it would be useful to replace a
language alien to the core with another alien ?
Well python is not alien, since we ship a tiny (~1.7Mb) python run-time
with every copy of LibreOffice we ship; ie. it is more built-in than
Java which is (sadly) not ubiquitous, and 10x larger.

Incidentally, the side effect of not having Java around, or worse
having a broken / mis-detected Java on an install is a slew of annoying
dialogs when you start LibreOffice from the various extensions that want
it; eg. five in a row of the form:

"Can I annoy you right now ?! [yes!]"

;-) a terrible user experience. I'd like to loose that: indeed working
on that would help reduce the need to prune Java stuff. The other option
of shipping a vast chunk of cruft we don't need to bundle, and use
almost none of is less attractive. Furthermore, Java has this unpleasant
GC that complicates debugging by hooking various signals, and has in the
past caused all manner of problems: eg. leaving invalid guard pages
around on the stack causing apparently un-related crashes later, and so
on. ie. I would really like to see Java relegated to a nice-but-optional
thing that in practise is not on the hot path for most people.
Post by Thorsten Guenther
I guessed the replacement of Java is to eliminate integration issues.
Primarily; true. However, Java's startup performance is mythically
terrible; eg. porting from Java -> C++ for the flat ODF export turned a
four seconds export (for a simple file, the first time) down to sub one
second. This is not the case for our embedded python I think.
Post by Thorsten Guenther
If that's not the case... whats the problem with Java? Just the
"is a appropriate JRE / JDK installed" issue?. Sorry, perhaps
a noob question
Not at all - a good question :-) I appreciate if your mission is to
drive Java deployment everywhere then perhaps the answer is not one that
everyone will like. Perhaps the best thing to do for Java is to try to
work on the C++ code paths, and error notification code for cases where
it is not present, particularly on Windows.

All the best,

Michael.
--
michael.meeks-Et1tbQHTxzrQT0dZR+***@public.gmane.org <><, Pseudo Engineer, itinerant idiot
Thorsten Guenther
2011-01-28 13:46:02 UTC
Permalink
Post by Michael Meeks
Post by Thorsten Guenther
could you please give me an idea why it would be useful to replace a
language alien to the core with another alien ?
Well python is not alien, since we ship a tiny (~1.7Mb) python run-time
with every copy of LibreOffice we ship; ie. it is more built-in than
Java which is (sadly) not ubiquitous, and 10x larger.
Incidentally, the side effect of not having Java around, or worse
having a broken / mis-detected Java on an install is a slew of annoying
dialogs when you start LibreOffice from the various extensions that want
"Can I annoy you right now ?! [yes!]"
;-) a terrible user experience. I'd like to loose that: indeed working
on that would help reduce the need to prune Java stuff. The other option
of shipping a vast chunk of cruft we don't need to bundle, and use
almost none of is less attractive. Furthermore, Java has this unpleasant
GC that complicates debugging by hooking various signals, and has in the
past caused all manner of problems: eg. leaving invalid guard pages
around on the stack causing apparently un-related crashes later, and so
on. ie. I would really like to see Java relegated to a nice-but-optional
thing that in practise is not on the hot path for most people.
...
Post by Michael Meeks
Post by Thorsten Guenther
If that's not the case... whats the problem with Java? Just the
"is a appropriate JRE / JDK installed" issue?. Sorry, perhaps
a noob question
Not at all - a good question :-) I appreciate if your mission is to
drive Java deployment everywhere then perhaps the answer is not one that
everyone will like. Perhaps the best thing to do for Java is to try to
work on the C++ code paths, and error notification code for cases where
it is not present, particularly on Windows.
Well, sadly I dont know a thing about the technical issues embedding a
jvm in an c application. Perhaps some of the user experience (apart from
download size) could be solved by shipping a "private" JVM with LO, but
this will have some legal issues to take care about.
So, since me looks like a lone java cowboy in friendly c land here (some
pythons sneaking around :-) I will just care about a scope that I can
handle:

I would like to provide a Java-API for remote controlling LO. That is
what can be done today with the UNO API. So the new API should be
implemented as wrapper, hiding as much UNO'isms as possible, presumably
for the cost of reduced functionality. Goal is to provide a friendly
looking tool for Java (or any JVM-Language) developers who want to
automate Document creation / manipulation with LO.

I hope this will get some more Java crowd attracted while the embedded
Java stuff can be removed. Assuming that the IDL / UNO / Java class
generation parts are there to stay..

If this this is of interest for the LO-community I would like to write
up some thoughts on the Wiki at the appropriate place. Any hint where
this would be?

Thanks
Thorsten Guenther
Michael Meeks
2011-01-28 13:58:13 UTC
Permalink
Hi Thorsten,
Post by Thorsten Guenther
Well, sadly I dont know a thing about the technical issues embedding a
jvm in an c application. Perhaps some of the user experience (apart from
download size) could be solved by shipping a "private" JVM with LO, but
this will have some legal issues to take care about.
Sure.
Post by Thorsten Guenther
I would like to provide a Java-API for remote controlling LO. That is
what can be done today with the UNO API. So the new API should be
implemented as wrapper, hiding as much UNO'isms as possible, presumably
for the cost of reduced functionality. Goal is to provide a friendly
looking tool for Java (or any JVM-Language) developers who want to
automate Document creation / manipulation with LO.
Almost certainly you want to get involved with the existing odf toolkit
project: http://odftoolkit.org/ they have a new Java API that does this
- though not using LibreOffice.

HTH,

Michael.
--
michael.meeks-Et1tbQHTxzrQT0dZR+***@public.gmane.org <><, Pseudo Engineer, itinerant idiot
Thorsten Guenther
2011-01-28 14:39:37 UTC
Permalink
Hi Michael,
Post by Michael Meeks
Almost certainly you want to get involved with the existing odf toolkit
project: http://odftoolkit.org/ they have a new Java API that does this
- though not using LibreOffice.
No, they created a stand alone lib. Great for running headless in your
appserver. I remember OOo was raped to do such things in the past. I
want LO to, for example, create an invoice or report from some backends
data and present it to the user for further editing. Some interaction
with the user would be desirable, to let him select some additional Data
or something.

Greetings
Thorsten Guenther
BRM
2011-01-28 14:55:11 UTC
Permalink
----- Original Message ----
Post by Thorsten Guenther
Hi Michael,
Almost certainly you want to get involved with the existing odf
toolkit
Post by Thorsten Guenther
project: http://odftoolkit.org/ they have a new Java API that does this
- though not using LibreOffice.
No, they created a stand alone lib. Great for running headless in your
appserver. I remember OOo was raped to do such things in the past. I
want LO to, for example, create an invoice or report from some backends
data and present it to the user for further editing. Some interaction
with the user would be desirable, to let him select some additional Data
or something.
Why go through the effort of (i) scripting LO and (ii) enabling your application
to do that, when you could simply
just make a UI to (a) show the existing document to the user in a view mode
(read-only), (b) get the specific data you need in your application,
presenting controlled interfaces to do so, and (c) write the ODF document
yourself?

While it may seem easier to incorporate an existing product like LO to do the
document editing for you; it is likely far
easier to just do it yourself and use a tool like ODF Tool Kit to write the
output document and load it for display - at the very least,
showing the user the output document with any kind of program (LO, OOo,
Symphony, Calligra, etc.) would be very easy to do without having to enhance any
of them for scripting.

$0.02

Ben
Thorsten Guenther
2011-01-28 15:48:06 UTC
Permalink
Hi Ben,
Post by BRM
Why go through the effort of (i) scripting LO and (ii) enabling your application
to do that, when you could simply
just make a UI to (a) show the existing document to the user in a view mode
(read-only), (b) get the specific data you need in your application,
presenting controlled interfaces to do so, and (c) write the ODF document
yourself?
While it may seem easier to incorporate an existing product like LO to do the
document editing for you; it is likely far
easier to just do it yourself and use a tool like ODF Tool Kit to write the
output document and load it for display - at the very least,
showing the user the output document with any kind of program (LO, OOo,
Symphony, Calligra, etc.) would be very easy to do without having to enhance any
of them for scripting.
$0.02
Ben
thanks for you thoughts. I want to be as close as possible to the office
application. For example the user could create document templates with
defined field names which are populated with external data. Sure there
are solutions for every scenario to avoid using and scripting LO but I
see value in providing this kind of functionality in an office context.

Regards
Thorsten Guenther
Wols Lists
2011-01-28 20:23:21 UTC
Permalink
Post by Thorsten Guenther
Hi Michael,
Post by Michael Meeks
Almost certainly you want to get involved with the existing odf toolkit
project: http://odftoolkit.org/ they have a new Java API that does this
- though not using LibreOffice.
No, they created a stand alone lib. Great for running headless in your
appserver. I remember OOo was raped to do such things in the past. I
want LO to, for example, create an invoice or report from some backends
data and present it to the user for further editing. Some interaction
with the user would be desirable, to let him select some additional Data
or something.
Having done that sort of thing ...

The backend should be able to talk basic XML. That gives us two options.

Bear in mind I was dealing with a lot of data ... our first attempt was
a mailmerge. This was actually rather slow, cumbersome, and prone to
errors. The second attempt was an "active document" if I can call it
that. A bit like a WordPerfect macro, you can build a document using it.
The third attempt was simply to get the database to spit out rtf
documents (which it did quite well, actually).

But as for your examples of invoices or reports, I think they are
actually very BAD examples of things that require inter-active post
processing. In America, that could very easily be a Sarbanes-Oxley
violation. Pretty much anywhere, it's likely to be a violation of GAAP.
And ime the volume will simply overwhelm you anyway.

I don't want to say "don't do it", but I think the market for what
you're proposing will be very limited - either you don't want / can't
handle interactivity, or a simple mailmerge will do. There's actually
almost no space between those two extremes.

Cheers,
Wol

Kohei Yoshida
2011-01-28 14:06:17 UTC
Permalink
Post by Thorsten Guenther
I would like to provide a Java-API for remote controlling LO. That is
what can be done today with the UNO API. So the new API should be
implemented as wrapper, hiding as much UNO'isms as possible,
presumably
for the cost of reduced functionality. Goal is to provide a friendly
looking tool for Java (or any JVM-Language) developers who want to
automate Document creation / manipulation with LO.
Someone else has tried something very similar there many years ago.

http://sao.sourceforge.net/

The project may have been abandoned by now (sure looks like it), but
perhaps you can pick up his basic ideas or (license permitting) his code
to start from.

Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
<kyoshida-Et1tbQHTxzrQT0dZR+***@public.gmane.org>
Thorsten Guenther
2011-01-28 14:51:04 UTC
Permalink
Hi Kohei,
Post by Kohei Yoshida
Someone else has tried something very similar there many years ago.
http://sao.sourceforge.net/
The project may have been abandoned by now (sure looks like it), but
perhaps you can pick up his basic ideas or (license permitting) his code
to start from.
thanks for the pointer. SAO seems to thin for me to really conceal UNO
from the developer. I would love if the developer don´t has to know
which interfaces are exported by a service. In fact he should not know
what a UNO-service is. That knowledge should be coded in the API. Don't
know if its possible and practical to be that abstract but I will try. :-)

Regards
Thorsten Guenther
Samphan Raruenrom
2011-01-27 10:32:48 UTC
Permalink
Another idea for a shorter-term solution for this is, instead of web-based
LibO, someone make a synchronization software that relay changes between
off-line ODF and online Google Docs, a la Google Cloud Connect for MS
Office.

Working with Google Docs is somewhat painful because it still lacks many
familiar features. An ideal solution would be to use a fat client that store
the ODF in the cloud. Many users can use the fat client to edit the document
at the same time while the synchronization software relay the changes made
by different users. Google Docs would be nice as the cloud storage except
that ODF lost a lot of formatting when convert to Google Docs.
Post by Michael Meeks
Hi Ged,
Post by Ged Wed
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 :-)
Post by Ged Wed
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 :-)
Post by Ged Wed
- 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 ? :-)
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.
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.
HTH,
Michael.
--
_______________________________________________
LibreOffice mailing list
http://lists.freedesktop.org/mailman/listinfo/libreoffice
--
_/|\_ Samphan Raruenrom. Open Source Development Co., Ltd.
Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/
Charles-H. Schulz
2011-01-27 11:55:57 UTC
Permalink
Hello there,

Indeed, a first step would be an extension that could store documents
on Dropbox and Ubuntu One... what do others think?

best,
Charles.

Le Thu, 27 Jan 2011 17:32:48 +0700,
Post by Samphan Raruenrom
Another idea for a shorter-term solution for this is, instead of
web-based LibO, someone make a synchronization software that relay
changes between off-line ODF and online Google Docs, a la Google
Cloud Connect for MS Office.
Working with Google Docs is somewhat painful because it still lacks
many familiar features. An ideal solution would be to use a fat
client that store the ODF in the cloud. Many users can use the fat
client to edit the document at the same time while the
synchronization software relay the changes made by different users.
Google Docs would be nice as the cloud storage except that ODF lost a
lot of formatting when convert to Google Docs.
On Mon, Jan 24, 2011 at 10:03 PM, Michael Meeks
Post by Michael Meeks
Hi Ged,
Post by Ged Wed
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 :-)
Post by Ged Wed
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 :-)
Post by Ged Wed
- 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
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 ? :-)
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.
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.
HTH,
Michael.
--
_______________________________________________
LibreOffice mailing list
http://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Charles-H. Schulz
Membre du Comité exécutif
The Document Foundation.
Michael Meeks
2011-01-27 12:18:14 UTC
Permalink
Post by Charles-H. Schulz
Indeed, a first step would be an extension that could store documents
on Dropbox and Ubuntu One... what do others think?
This probably belongs on the discuss list. Can we talk development:
patches, code details, tangled bugs, and concrete contributions etc.
here ? :-)

Thanks,

Michael.
--
michael.meeks-Et1tbQHTxzrQT0dZR+***@public.gmane.org <><, Pseudo Engineer, itinerant idiot
Ged Wed
2011-01-27 14:46:41 UTC
Permalink
Hey all,

Yeah i thought about Google Docs synchronisation. For example this is what i
do now but a more manual process.
It does work, but as you say you loose fidelity because google docs is not
Open Office.

I cant help but think that the purist way of rendering directly using html5
and JavaScript specifically off an unpackaged open office word doc is a
better approach.
Again here is the idea:
1. Client side unpacking and packing. JS can do this and handle
the various aspects of this.
- I node that using NodeJS we can leverage doing all aspects either server
side or client side thats to CommonJS standard.

2. The XML is rendered to the dom, and then "compiled" using angularJS in
order to re-render the various parts of the XML.
- For each XML part of namespace a controller and view
rendering mechanism is available with AngularJS which is very concise.

3. Some standard interaction GUI controls can be used for common things like
"search and Replace, style, file IO, notifications etc.
The idea is not to completely implement the OO functionality for Word docs,
but to just give basic editing.
Because the the way AngularJS works anything NOT implemented off the XML is
still able to be reproduced in the XML to COM conversion and back from DOM
to XML again.

Now the question is this:
1. What parts of this can be leveraged off the current code base to be done
server side ? SOme ideas:
a. Packaging and unpacking
b. Data data extraction out of the XML fragments ?

Regards

Gerard
Post by Michael Meeks
Post by Charles-H. Schulz
Indeed, a first step would be an extension that could store documents
on Dropbox and Ubuntu One... what do others think?
patches, code details, tangled bugs, and concrete contributions etc.
here ? :-)
Thanks,
Michael.
--
Ged Wed
2011-01-27 14:55:03 UTC
Permalink
I just want to add that the idea of using Google Docs and the WedDav aspects
is a good first step.
Sure it allows seamless editing via the web and synchronisation back to your
own harddisk OR cloud harddisk.

But its a first step. I think that getting a XML to DOM component that
is JavaScript based would be a better approach.
I knwo its very ambitious but its amazing how powerful JS is these days in
browsers.
Also i think a read only version would be a good first step.
For that a read / write version could be done in stages
implementing various functionality progressively.

This is very hard stuff but i think trying out a prototype to do the XML to
DOm conversion with AngularJS is worthwhile.
I want to add that the xml namespace to JS binding is apr of AngularJS. Its
how it "just works". So its a very concise solution with high encapsulation.
Many people ( including me) are afraid of JS because its untyped, and so
hard to work with large code bases. I agree, but the thing i noticed about
AngularJS is how it can map XML to DOM very easily and with high
encapsulation to whatever fragment in the XML document you bind to.

I just dont know the Open Office code base well enough to know what server
side parts can be leveraged.
Any C code can be leverage server side using a Ajax style approach using the
logic encapsulated inside the c libraries, and exposed on the client side
perhaps.

G
Post by Ged Wed
Hey all,
Yeah i thought about Google Docs synchronisation. For example this is what
i do now but a more manual process.
It does work, but as you say you loose fidelity because google docs is not
Open Office.
I cant help but think that the purist way of rendering directly using html5
and JavaScript specifically off an unpackaged open office word doc is a
better approach.
1. Client side unpacking and packing. JS can do this and handle
the various aspects of this.
- I node that using NodeJS we can leverage doing all aspects either server
side or client side thats to CommonJS standard.
2. The XML is rendered to the dom, and then "compiled" using angularJS in
order to re-render the various parts of the XML.
- For each XML part of namespace a controller and view
rendering mechanism is available with AngularJS which is very concise.
3. Some standard interaction GUI controls can be used for common things
like "search and Replace, style, file IO, notifications etc.
The idea is not to completely implement the OO functionality for Word docs,
but to just give basic editing.
Because the the way AngularJS works anything NOT implemented off the XML is
still able to be reproduced in the XML to COM conversion and back from DOM
to XML again.
1. What parts of this can be leveraged off the current code base to be done
a. Packaging and unpacking
b. Data data extraction out of the XML fragments ?
Regards
Gerard
Post by Michael Meeks
Post by Charles-H. Schulz
Indeed, a first step would be an extension that could store documents
on Dropbox and Ubuntu One... what do others think?
patches, code details, tangled bugs, and concrete contributions etc.
here ? :-)
Thanks,
Michael.
--
Ged Wed
2011-01-27 21:07:01 UTC
Permalink
If i can also add to this discussion abut why i am pushing this way.

The w3c is already adopting a standards for apps the mimic the way packing
is done for Open Office and MS Office documents
http://www.w3.org/TR/widgets/

This whole conversation comes out of the current mobile app stored debate
happening here:
http://www.quirksmode.org/blog/archives/2010/03/html5_apps.html

The short conclusion is that that a browser has Tabs and the interaction of
"Intents" ( a android term ) are not composable and understandable between
tabs. Tabs are a stop gap to the fact that there is no Desktop, File System,
etc available to just a browser.
So at the end of the day, the W3C Widget packaging and
configuration<http://www.w3.org/TR/widgets/> spec
represents a move by which the browser is able to become the OS.

Now i don't want to get hit over the head with "your using a sledgehammer to
crack a nut" and "when you have a nutcracker, every problem looks like a
nut" etc etc. All i am getting at is that Open Office has an opportunity to
make a huge leap forward by embracing the clear path that is going forward.
And what better example. Open Office intents between
the various applications it represents. For example Writer and Speadsheet
apps are able to act as widgets sharing data and intentions between them.

Ged





<http://www.w3.org/TR/widgets/>
Post by Ged Wed
I just want to add that the idea of using Google Docs and the WedDav
aspects is a good first step.
Sure it allows seamless editing via the web and synchronisation back to
your own harddisk OR cloud harddisk.
But its a first step. I think that getting a XML to DOM component that
is JavaScript based would be a better approach.
I knwo its very ambitious but its amazing how powerful JS is these days in
browsers.
Also i think a read only version would be a good first step.
For that a read / write version could be done in stages
implementing various functionality progressively.
This is very hard stuff but i think trying out a prototype to do the XML to
DOm conversion with AngularJS is worthwhile.
I want to add that the xml namespace to JS binding is apr of AngularJS. Its
how it "just works". So its a very concise solution with high encapsulation.
Many people ( including me) are afraid of JS because its untyped, and so
hard to work with large code bases. I agree, but the thing i noticed about
AngularJS is how it can map XML to DOM very easily and with high
encapsulation to whatever fragment in the XML document you bind to.
I just dont know the Open Office code base well enough to know what server
side parts can be leveraged.
Any C code can be leverage server side using a Ajax style approach using
the logic encapsulated inside the c libraries, and exposed on the client
side perhaps.
G
Post by Ged Wed
Hey all,
Yeah i thought about Google Docs synchronisation. For example this is what
i do now but a more manual process.
It does work, but as you say you loose fidelity because google docs is not
Open Office.
I cant help but think that the purist way of rendering directly using
html5 and JavaScript specifically off an unpackaged open office word doc is
a better approach.
1. Client side unpacking and packing. JS can do this and handle
the various aspects of this.
- I node that using NodeJS we can leverage doing all aspects either server
side or client side thats to CommonJS standard.
2. The XML is rendered to the dom, and then "compiled" using angularJS in
order to re-render the various parts of the XML.
- For each XML part of namespace a controller and view
rendering mechanism is available with AngularJS which is very concise.
3. Some standard interaction GUI controls can be used for common things
like "search and Replace, style, file IO, notifications etc.
The idea is not to completely implement the OO functionality for Word
docs, but to just give basic editing.
Because the the way AngularJS works anything NOT implemented off the XML
is still able to be reproduced in the XML to COM conversion and back from
DOM to XML again.
1. What parts of this can be leveraged off the current code base to be
a. Packaging and unpacking
b. Data data extraction out of the XML fragments ?
Regards
Gerard
Post by Michael Meeks
Post by Charles-H. Schulz
Indeed, a first step would be an extension that could store documents
on Dropbox and Ubuntu One... what do others think?
patches, code details, tangled bugs, and concrete contributions etc.
here ? :-)
Thanks,
Michael.
--
Michael Meeks
2011-01-27 11:46:48 UTC
Permalink
Hi Samphan,
Post by Samphan Raruenrom
Another idea for a shorter-term solution for this is
Great - there is an existing google docs connector out there; it
shouldn't be too hard to make this integration better; in particular by
re-writing it to be native C++, and integrating it with the product. I
imagine using webdav is what it uses.

It would be wonderful to have someone hacking on improving our built-in
integration with various CMS; some CMS icon in the shell, a nice
configurable browser in the file-menu even ? etc. ?

Are you going to work on that ? if so, grab us on IRC for some hints as
to where to dig in the code.

ATB,

Michael.
--
michael.meeks-Et1tbQHTxzrQT0dZR+***@public.gmane.org <><, Pseudo Engineer, itinerant idiot
Continue reading on narkive:
Loading...