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