Re: [Libreoffice] web based libre office

[Ged Wed]

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 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







On 27 January 2011 15:55, Ged Wed  wrote:

> 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
>
>
> On 27 January 2011 15:46, Ged Wed  wrote:
>
>> 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
>>
>> On 27 January 2011 13:18, Michael Meeks  wrote:
>>
>>>
>>> On Thu, 2011-01-27 at 12:55 +0100, Charles-H. Schulz wrote:
>>> > 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

Re: [Libreoffice] web based libre office

[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

On 27 January 2011 15:46, Ged Wed  wrote:

> 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
>
> On 27 January 2011 13:18, Michael Meeks  wrote:
>
>>
>> On Thu, 2011-01-27 at 12:55 +0100, Charles-H. Schulz wrote:
>> > 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot
>>
>>
>>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[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.
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

On 27 January 2011 13:18, Michael Meeks  wrote:

>
> On Thu, 2011-01-27 at 12:55 +0100, Charles-H. Schulz wrote:
> > 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot
>
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Michael Meeks]

On Thu, 2011-01-27 at 12:55 +0100, Charles-H. Schulz wrote:
> 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Michael Meeks]

Hi Samphan,

On Thu, 2011-01-27 at 17:32 +0700, Samphan Raruenrom wrote:
> 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Charles-H. Schulz]

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,
Samphan Raruenrom  a écrit :

> 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
> 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 :-)
> >
> > > - 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot
> >
> >
> > ___
> > LibreOffice mailing list
> > LibreOffice@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libreoffice
> >
> 
> 
> 



-- 
Charles-H. Schulz
Membre du Comité exécutif
The Document Foundation.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Michael Meeks]

Hi Jonathan,

On Thu, 2011-01-27 at 09:36 +0100, Jonathan Aquilina wrote:
> > Either way - I don't think this discussion really
> > belongs here - sorry.
..
> 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[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 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 :-)
>
> > - 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot
>
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> 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/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Jonathan Aquilina]

On 1/24/11 5:53 PM, Michael Meeks wrote:

Hi Ged,

So - thank you for your nice ideas :-) we can setup a list for this
discussion: crack-smoking-re-write-everyhing-in-javascr...@tdf.org or
somesuch ? :-)

On Mon, 2011-01-24 at 17:17 +0100, Ged Wed wrote:

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 ;-)


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 :-)


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).


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  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?

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Michael Meeks]

Hi Ged,

So - thank you for your nice ideas :-) we can setup a list for this
discussion: crack-smoking-re-write-everyhing-in-javascr...@tdf.org or
somesuch ? :-)

On Mon, 2011-01-24 at 17:17 +0100, Ged Wed wrote:
> 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 ;-)

> 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 :-)

> 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).

> 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  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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Ged Wed]

On 24 January 2011 16:03, Michael Meeks  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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot
>
>
>

Gerard
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] web based libre office

[Michael Meeks]

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 :-)

> - 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.me...@novell.com  <><, Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] web based libre office

[Ged Wed]

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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice