corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriela Gibson <gabriela.gib...@gmail.com>
Subject Re: [CONF] Corinthia > ODF
Date Thu, 12 Mar 2015 09:37:45 GMT
On Thu, Mar 12, 2015 at 2:37 AM, Dennis E. Hamilton <dennis.hamilton@acm.org
> wrote:

> Replying to both Gabriela and Jan comments farther below,
>
>  1. The TL;DR: Even though there are people still using StarOffice on a
> Sun Workstation, I don't think these are a significant component of likely
> Corinthia users.  Our use of an intermediary is not likely to get us to
> universal interconvertibility.
>
> (Peter: this also addresses your point :)

I'm not saying we should actually do this (now).

The question really is:  Can we plan now for this to be possible, at a
later time?  And, can we get this possibility cheaply, en passant?

That is, is there an elegant way in which to set up the architecture of
this code, so that someone can easily add inter-convertibility later on?

Also, say Corinthia gets to be (woo!) 20.  We're (say) at ODF 6.0.  Given
the entire reason for ODF is the users' data freedom (that is you own your
data and not some company and their fancy format), does it not behoove us
not to allow versions of ODF own the users data?

Likewise, if possible, we should not limit tomorrows' committers either by
our design decision today.

If it's a PITA, then it of course should not be attempted, but ... if we
can lunch for free, then please pass the ketchup! ;-)

Also, what Dennis wrote below makes me think that much future pain can be
avoided if we can pull such a design structure off.

Question for Dennis:  Where do you think ODF will be in 20 years time?

G


 2. It is necessary to support input of all versions that are known
> especially because if a document says it is in ODF 1.2, that does not mean
> it uses any features that are not in ODF 1.1, and if it is one of the
> breaking cases, that can be handled if there is enough information about
> the intended level of ODF.  (But an ODF 1.2 implementation might still be
> implementing an ODF 1.1 interpretation.).
>      For output, if it is not possible to indicate the actual level of
> features employed, it is usually necessary to identify outputs as ODF 1.2.
>
> 3. IMPORTANT EXCEPTION: If the DocFilter implementations for ODF input and
> ODF updating do not preserve any features used above a given ODF level,
> that level should be indicated as the output level.  (I.e., if ODF
> 1.2-unique features are not even supported, don't call the output ODF 1.2,
> no matter what the input is claimed to be.)
>
> This might well be a significant part of spiral development and
> progressive integration of an ODF-support roadmap.
>
>  - Dennis
>
> -----Original Message-----
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: Wednesday, March 11, 2015 16:43
> To: dev@corinthia.incubator.apache.org
> Cc: dennis.hamilton@acm.org
> Subject: Re: [CONF] Corinthia > ODF
>
> On Wed, Mar 11, 2015 at 11:02 PM, jan i <jani@apache.org> wrote:
>
> [ ... ]
> > In my opinion, we must be able to  read all versions, but only write the
> > newest.
> >
> > This is a bit devil's advocate tale, but, it's a true story:
>
> [ ... ]
>
> So, there will be occasions where people will want to be able to use a
> legacy program, because it makes life easier for them, or perhaps, an old
> machine is all they can afford, or they simply don't want to enter upgrade
> hell.  When ODF 6.0 comes round (and it probably will, eventually) there
> will be lots of people wanting/needing this kind of functionality.
>
> Also, Hackernews had an interesting discussion today:
> https://news.ycombinator.com/item?id=9185356  --- maybe not quite
> applicable to our situation here, but pretty similar.
>
> I think it's worthwhile to consider to make it bidirectional by basic
> design.
>
> G
>
>
>


-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message