corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COR-11) Make interface between docformat and webkit (prepare for e.g. Qt).
Date Mon, 19 Jan 2015 16:32:35 GMT

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

Mime
View raw message