Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
Date: Mon, 19 Jan 2015 16:32:35 +0000 (UTC)
From: "Dennis E. Hamilton (JIRA)" <jira@apache.org>
To: dev@corinthia.incubator.apache.org
Message-ID: <JIRA.12762945.1419015956000.116617.1421685155089@Atlassian.JIRA>
In-Reply-To: <JIRA.12762945.1419015956000@Atlassian.JIRA>
References: <JIRA.12762945.1419015956000@Atlassian.JIRA>
 <JIRA.12762945.1419015956111@arcas>
Subject: [jira] [Commented] (COR-11) Make interface between docformat and
 webkit (prepare for e.g. Qt).
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282668#comment-14282668 ] 

Dennis E. Hamilton commented on COR-11:
---------------------------------------

The coin dropped on what I think is awkward about my understanding of what is happening (which I would like very much to be corrected about).

Using the previous stages, here is what appears to be involved.

In stage 2, there is a conversion, Vodt(d1) -> Hd1 from a document file, d1, to an HTML file, Hd1.  This file reflects the document that is perceived as carried by d1 and also details of some kind about restraints and about features that are not being reflected but need to be retained in some fashion.  So there are markers and annotation of some sort in the Hd1.

In stage 5, there is an editing process, Eodt(d1, DHd1) -> d2.  Note that this is a full editor.  We did view already, but now we have an editing process that basically has a persistent document-file format taken in, along with however the Hd1 edits are expressed, to make a derived persistent document file of that (or possibly another) format.

There's also the case of making a fresh document.  I don't know if there is some sort of selection about what the intended document is up front, via an initial HTML template or what, but we end up with a Codt(DHd0) -> d1 or
perhaps Eodt(template, DHd0) -> d1.

So to have the persistent-form end-to-end process work, there are a variety of invariants that have to be sustained or there will be mystery defects and breakage (and the kind of "some features may be lost" warnings) that make users crazy.

My provisional take-aways:

 1. Orchestration requires constraints that the stages have to honor in order for the complete tool-chain to provide a reliable result with expected fidelity.

 2. There are three important cases, one of which is in effect an editor of the persistent document-file format anyhow.  It isn't rendering a view and apparently not coupled interactively to a renderer.  That means there is a lot of common code and also redundant use of that code in the round-trip from document-file to HTML editing to document-file.

 3. There is a lot to be done in getting the modularization right.

 4. We need to understand and clearly-stipulate the scale limitations of this approach, if I have understood it in its essential form.

 5. We haven't considered distributed/collaborative real-time messing with documents at all, as far as I can tell.  I don't expect that.  But an approach to finer grain-modularity of interactions might anticipate some fundamental provisions that would enable extending into that area.  Maybe we just need to be clear with ourselves about that.

> Make interface between docformat and webkit (prepare for e.g. Qt).
> ------------------------------------------------------------------
>
>                 Key: COR-11
>                 URL: https://issues.apache.org/jira/browse/COR-11
>             Project: Corinthia
>          Issue Type: New Feature
>          Components: DocFormats - API
>         Environment: source
>            Reporter: jan iversen
>            Priority: Blocker
>             Fix For: 0.5
>
>
> We need a API to the library


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)