The new [QUESTION] is "What should a cloud-hosted/distributive/collaborative architecture for the future of Apache OpenOffice look like?"
- - - - - - - - - - Thanks Andrew. I agree that cloud and collaboration are big topics. And they are not the same as a platform port. It strikes me, at a 50,000 foot level, that it will require a significant re-architecture to provide moving parts that can be integrated into cloud-hosted/distributed collaborative operation, and this is a worthwhile new topic. I think some of the points below might be adaptable to such consideration, especially in doing proof-of-concept work. In your honor, I am forking off this thread to the question that you raise. (The Getting to AOO4J question continues to stand on its own, but presumably AOO4J might intercept the other matter by become a desktop application that can inter-work in that cloud-oriented, distributed-collaboration future.) - Dennis > -----Original Message----- > From: Andrew Rist [mailto:andrew.r...@oracle.com] > Sent: Tuesday, November 17, 2015 10:17 > To: dev@openoffice.apache.org > Subject: Re: [QUESTION] Getting to AOO for Java (AOO4J)? > > Hope this is not off topic, but I think it should be a part of this > conversation. > If w are looking at moving AOO forward, then we should be looking > forward and not just porting to another development platform. > As such, the two most important destinations are a cloud implementation > and collaboration. I do think java (plus javascript on a browser on the > client) is the best way to move in that direction, and the first step > would be to port AOO (or at least large portions) to java. > Of course, this project would be an order of magnitude harder than just > porting, but it is the way we could move forward, and not just provide > another port of the current product. > > A. > > On 11/15/2015 12:06 PM, Dennis E. Hamilton wrote: > > Damjan, > > > > I am not digging into the details of how one might do a top-down > conversion to an AOO4J. > > > > However, there are bidirectional dependencies that have to be > accounted for when Java is on top of native GUI-using and exception- > generating code. In my one adventure into JNI, > > <http://odma.info/dev/devNotes/2007/07/d070701.htm>, I discovered how > upward native dependencies matter when the native code presents a modal > dialog against the native Window that the Java level creates and uses. > I suspect that is a far more elaborate problem in the case of an AOO4J. > (I also never passed up an exception or produced a null result.) > > > > Since the top-down method that is proposed would require working > against the Apache OpenOffice source, I would recommend the following > > > > 1. A proof-of-concept be undertaken on a parallel section of the SVN, > > at <https://svn.apache.org/repos/asf/openoffice/>. (It is more > than > > a branch, it seems to me.) > > > > 2. The proof-of-concept should somehow provide adequate functionality > to > > demonstrate that all cases of OpenOffice functionality can be > > accommodated. There needs to be confidence in such an outcome. > > > > 3. The proof-of-concept must extend all the way to deployment and how > > deployment of released binaries would be undertaken. This also > > must address localization and QA in some manner. > > > > 4. The idea is to identify everything that needs to be accounted for > > in making such a conversion, and to expose any show-stoppers as > > early as possible. > > > > 5. Working on the proof-of-concept must not extend the critical path > > for maintenance and release of software on the current AOO 4.x > > line. This is perhaps the single most-critical requirement. > > > > The actual determination to pursue farther would be a matter for the > Project Management Committee and the AOO developer community to work out > as a matter of project governance. That is not on the table at the > moment. I suggest that the question not be entertained in the absence > of a proof-of-concept around which there is confidence that all > considerations can be addressed. > > > > - Dennis > > > >> -----Original Message----- > >> From: Damjan Jovanovic [mailto:dam...@apache.org] > >> Sent: Sunday, November 8, 2015 00:58 > >> To: Apache OO <dev@openoffice.apache.org> > >> Subject: Re: [QUESTION] Getting to AOO for Java (AOO4J)? > >> > >> Let's examine porting AOO to Java in more detail. > >> > >> Java can easily call C code with JNA and also easily call even C++ > with > >> BridJ (https://github.com/nativelibs4java/BridJ) (with its sister > >> project > >> JNAerator even generating Java code to compile/link yours against by > >> examining C/C++ header files), and Java can easily call any UNO > >> component. > >> C/C++ on the other hand can only call Java with great pain using the > >> Java > >> invocation API, but UNO wraps that for us, so a Java component can be > >> called as easily as any UNO component. So ideally the smallest unit > of > >> granularity while converting should be an UNO component, and C++ -> > Java > >> call flow should be avoided. > >> > >> The easiest way to avoid C++ -> Java calls is to convert top down, > >> starting > >> with top level modules like main/desktop and working down. But if A > uses > >> B, > >> and A is ported to Java and calls B using JNA/BridJ, then when B is > also > >> ported to Java, A's calls to B need to be ported from JNA/BridJ to > pure > >> Java, so working top down, while easier, means a 2 phase porting > process > >> is > >> necessary. Porting modules that are only accessed via UNO, would > avoid > >> the > >> 2 phase problem as UNO would be used before and after; > main/xmlsecurity > >> which is only accessed via UNO and needs the category B nss library, > is > >> on > >> the chopping block :-). > >> > >> The how of porting is maybe the most interesting. For the migration > from > >> CppUnit to Google Test I did recently, the only reason I finished > such a > >> massive undertaking in the time that I did, is that I quickly > developed > >> a > >> tool to parse source code and convert the API. The tens of thousands > of > >> calls to CPPUNIT_ASSERT* in our source tree didn't require hundreds > of > >> thousands of keystrokes. Most of my time was spent on the stuff that > >> couldn't be automated, like migrating makefiles, fixing failing > tests, > >> and > >> hooking the tests into the build. My migration attempt from dmake to > >> gbuild > >> - 100% manually - has been a disaster by comparison: only > main/formula > >> was > >> migrated so far - even the tiny 4 file main/animations module > >> mysteriously > >> crashes Impress when ported, and 1 test in main/tools doesn't link on > >> Windows... > >> > >> I only consider the port to Java feasible because it could be mostly > >> automated. A while ago I discovered cpp-to-java-source-converter ( > >> https://github.com/danfickle/cpp-to-java-source-converter), a > compiler > >> that > >> converts C++ to Java. It's written in Java, under the ASLv2. It uses > the > >> C++ parser from the Eclipse CDT project. It's still incomplete, very > >> slow, > >> full of errors, and it produces Java code even more complex than the > C++ > >> was. But I played with it, fixed a few bugs, forked it ( > >> https://github.com/DamjanJovanovic/cpp-to-java-source-converter) and > am > >> working on more improvements. And with some further work, I think it > has > >> real potential. Obviously not all C++ code can be converted to Java: > >> goto > >> statements, iterating a char pointer over a struct, and so on, but > those > >> are rare and can always be converted manually. But for the rest, and > >> with > >> some improvements to cpp-to-java-source-converter, the Java code > >> produced > >> could be of very high quality: elimination of destructors that only > >> release > >> memory, the rest converted to close() and RAII implemented as Java > 7's > >> try-with-resources, pointer iteration converted to indexing or Java > >> iterators and possibly the enhanced for loop, etc. > >> > >> Also cpp-to-java-source-converter could be patched to output JNA or > >> BridJ > >> calls from the converted Java, and maybe to even do some API > remapping > >> in > >> place of calls to C++ APIs, like change ::std::map to java.util.Map. > >> > >> Of course, it won't all be that easy: comments in the code would have > to > >> be > >> copied to Java manually (and hopefully translated from German), > >> preprocessor #define constants need research, some C++ idioms will be > >> slow > >> in Java and need to be rewritten, etc. But I am hopeful that this is > >> still > >> the most promising path, which will produce the highest quality Java > >> code > >> in the shortest amount of time. > >> > >> Even if the goal is 100% Java, there would still be a long transition > >> period where we use C++ as well. We should also improve the user > >> experience > >> with Java before porting anything to Java. Then maybe we should start > by > >> porting the dodgy modules like xmlsecurity. > >> > >> Damjan > >> > >> On Sat, Nov 7, 2015 at 9:41 PM, Dennis E. Hamilton > <orc...@apache.org> > >> wrote: > >> > >>> There has been suggestion, and some expressed support, for AOO > >> becoming a > >>> Java application. > >>> > >>> I don't want to discuss the merits of this, but how it might be > >> undertaken. > >>> 1. NO STANDING-STILL ASSUMPTION. My first assumption is that one > >> can't > >>> cease Apache OpenOffice maintenance and support while something like > a > >>> redevelopment on Java occurs. It is pretty unthinkable that > >> development of > >>> a > >>> Java version can be accomplished inside the release cycle (even the > >> past > >>> lengthy cycle), and that migration from AOO as we know it can't be > >> done > >>> like > >>> throwing a switch on the universe. So, my first assumption, which > one > >> can > >>> challenge, is that any development of a Java version must happen > >> separate > >>> from the ongoing support for the current AOO. > >>> > >>> 2. FORKING TO MAKE AOO4J? One could consider making a project > fork. > >> That > >>> doesn't make sense as an Apache project, going through incubation, > >> having > >>> to > >>> do much from scratch. But one could make an independent fork of a > >>> Java-based AOO (near) workalike. It could be a GitHub project, for > >> example. > >>> If it is to come back to Apache, it must be sort of managed as an > >> Apache > >>> Project from the beginning, especially around license and code > >> provenance > >>> (IP) considerations. That might be too hard. > >>> > >>> 3. EXPANDING THE ODF TOOLKIT PROJECT. This is my favorite. The > >> Apache > >>> ODF > >>> Toolkit (incubating) project is Java-based already. It deals with > >> some > >>> fundamentals about supporting the OpenDocument Format (ODF). One > >> could > >>> imagine building up the modularization to the point where one could > >> achieve > >>> Writer, Calc, ... etc., workalikes. There, AOO4J could be a > >> demonstration > >>> of composition of a suite (or even standalone components with shared > >>> libraries). There are also available related applications for > >>> interoperability testing of the level of ODF support: Apache > >> OpenOffice > >>> itself, LibreOffice, and Microsoft Office. The support for > Microsoft > >>> Office > >>> native formats could come from the POI projects and other open- > source > >>> resources. > >>> > >>> The test of capacity is then one of how (2) or (3) manages to grow > >> into a > >>> thriving project. Meanwhile, AOO is sustained and there are no > >> diversions > >>> until a natural migration occurs. > >>> > >>> How does any of that sound. It means that there would be no > >> revolutionary > >>> disruption of the Apache OpenOffice project itself. > >>> > >>> - Dennis > >>> > >>>> -----Original Message----- > >>>> From: Dennis E. Hamilton [mailto:orc...@apache.org] > >>>> Sent: Tuesday, October 20, 2015 15:36 > >>>> To: dev@openoffice.apache.org > >>>> Subject: RE: [QUESTION] Optional Java Use for Essential > >> Functionality > >>>> Summary of what this thread revealed, in-line. > >>>> > >>> [ ... ] > >>>> [orcmid] There were some unexpected responses to these questions. > >>>> > >>>> 2. One suggestion was to remove the dependencies on Java. > >>>> > >>>> 3. Other suggestions included increasing the dependencies on Java, > >>>> perhaps > >>>> going so far as to make AOO a Java application. > >>>> > >>> [ ... ] > >>> > >>> > >>> -------------------------------------------------------------------- > - > >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
