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/> On 27 January 2011 15:55, Ged Wed <gedw99@gmail.com> 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 <gedw99@gmail.com> 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 <michael.meeks@novell.com> 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.meeks@novell.com <><, Pseudo Engineer, itinerant idiot