You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2011/08/03 17:49:46 UTC
binfilter (was RE: OOO340 to svn)
I believe LibreOffice is already taking action on binfilter, and it would be useful to see if we can match their approach.
Also, I think there was (again on LibreOffice) a technical discussion on simplifying the dependencies. This was initially by having redundancy, with the idea that a better refactoring would come later.
- Dennis
-----Original Message-----
From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
Sent: Tuesday, August 02, 2011 23:12
To: ooo-dev@incubator.apache.org
Subject: Re: OOO340 to svn
On Wed, Aug 3, 2011 at 12:28 AM, Eike Rathke <oo...@erack.de> wrote:
> Hi IngridvdM,
>
> On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
>
> > >The Hg archive should simply replicate the current structure at OOo,
> > >also for ease of adding in pending CWSs as branches, so a separate l10n
> > >repository.
> > >
> > Another good argument to separate l10n from trunk was given in an
> > earlier thread: This way it is easier for developers to get only
> > what they will need usually and spare the extra time and space.
> >
> > I think this is a good argument and I wonder whether we shouldn't be
> > prepared to identify more such stuff - for example the binfilter.
>
> The problem with binfilter is that it depends on modules not in
> binfilter, changing them incompatibly may entail changes necessary to
> binfilter, those changes should be in one changeset, which I think is
> not possible when not in trunk, insights anyone?
>
>
well binfilter is maybe not the best example because in the long term we
should think about the elimination of binfilter completely. Announcing the
end of life of these filters, then allow the import only for some time and
the next step is to drop it ...
Juergen
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Am 06.08.2011 19:45, schrieb Dennis E. Hamilton:
> " What does this show? Others behave much worse as we would do. If the
> first AOO release will be the last with binfilters and we assume a
> runnalble/installable state of 5-10 years (depending on OS, unforseeable
> progress, etc...) this will be fine from my POV."
>
> My concern about this rationale is that those of us who see no problem are making a likely irreversible decision that impacts those who do and may not even be aware of what we are doing.
Can never be excluded, we simply have no numbers. Remember, this means
we also have no numbers about how many people use it. No complains when
not installing it by default hints to no users.
OTOH we have numbers about time, space, bandwidth, buildtime
consumptions of binfilter. We know that it needs to be looked after.
Michael Stahl pointed to probable security relevant stuff in the old
binfilter parts (I guess he's right). We know that it builds with a lot
of warnings. Trying to remove those is ambitious, but OTOH dangerous,
may add errors to binfilters. Errors may be added by changes to
underlying modules with nearly no chance to find them. Even changing the
compiler may add unnoted errors.
In short: It does not come for free to simply keep it.
All in all:
Binfilter has done it's duty. It has allowed to do changes to the
internal core class hierarchy and more. It has allowed to have a
transition phase. Let's let it go...
> With regard to consumption versus production, I agree that it is easy to stop supporting production when no native consumers are likely to be available any longer and the OpenOffice.org document model evolves to support expanded functionality of further ODF specifications.
>
> So if we propose to retire binfilters, we need some way to make it clear that is happening and what the workarounds are for someone who finds themselves in need. And we definitely need to keep it in a form where someone could revive it at a later time, even if only part of some sort of document-forensics and -recovery/conversion effort rather than integrated into future releases.
Sure, agreed.
> This is not the last time we will need to deal with this (and the same fate could eventually befall the native format currently supported by OpenOffice.org.)
>
> Also, if there are available specifications, whatever their quality, we probably need to see to their preservation as well.
>
> - Dennis
>
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Am 09.08.2011 22:20, schrieb Mathias Bauer:
> On 09.08.2011 20:49, Armin Le Grand wrote:
>
...
>> Forgot one point: We are not talking about stopping support for
>> something like PDF/A where readability is guaranteed for years/decades.
>> We are talking about wildly, unplanned grown old binary filter formats
>> in the old days of the office where the model was simply streamed out
>> and in, patched and repaired many times, never documented (for good reason).
>
> And moreover, we are talking about a format that does not support a huge
> number of OOo feature, UniCode support being only one of them.
Right, also forgot but didn't want to write a 3rd part just 5min later :-)
Not only UniCode, all features since Binfilter was isolated, get lost in
an old write/read cycle with this old filters. Using them for write may
just have two reasons:
- You have an old machine with StarOffice5.2 or something which cannot
read ODF
- You don't know about losing content when using the old formats
> BTW: the reservation that legal requirements can force people to keep
> documents in the old binary StarOffice format is a red herring. I have
> serious doubts that any organization with such requirements has ever
> used this format. Remember, it's *not* an OOo format, it's the format of
> the pre-OOo StarOffice application that was replaced by the UniCode
> supporting XML format before OOo got its first release.
>
> For those with concerns that there might be some documents in the old
> format that "suddenly" needs to be opened, perhaps a standalone
> converter tool from "binfilter" to ODF could be provided. Wait a moment,
> that tools already exists: all existing OOo version can be used that way.
Exactly. Let the next AOO release be the last one to offer this.
BTW: For the concerned ones how long it might be installable: I'm still
using StarOffice5.2 sometimes for various things, still works well today :-)
> Regards,
> Mathias
>
Regards,
Armin
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 09.08.2011 20:49, Armin Le Grand wrote:
> Am 06.08.2011 19:45, schrieb Dennis E. Hamilton:
>> " What does this show? Others behave much worse as we would do. If the
>> first AOO release will be the last with binfilters and we assume a
>> runnalble/installable state of 5-10 years (depending on OS, unforseeable
>> progress, etc...) this will be fine from my POV."
>>
>> My concern about this rationale is that those of us who see no problem are making a likely irreversible decision that impacts those who do and may not even be aware of what we are doing.
>>
>> With regard to consumption versus production, I agree that it is easy to stop supporting production when no native consumers are likely to be available any longer and the OpenOffice.org document model evolves to support expanded functionality of further ODF specifications.
>>
>> So if we propose to retire binfilters, we need some way to make it clear that is happening and what the workarounds are for someone who finds themselves in need. And we definitely need to keep it in a form where someone could revive it at a later time, even if only part of some sort of document-forensics and -recovery/conversion effort rather than integrated into future releases.
>
> Forgot one point: We are not talking about stopping support for
> something like PDF/A where readability is guaranteed for years/decades.
> We are talking about wildly, unplanned grown old binary filter formats
> in the old days of the office where the model was simply streamed out
> and in, patched and repaired many times, never documented (for good reason).
And moreover, we are talking about a format that does not support a huge
number of OOo feature, UniCode support being only one of them.
BTW: the reservation that legal requirements can force people to keep
documents in the old binary StarOffice format is a red herring. I have
serious doubts that any organization with such requirements has ever
used this format. Remember, it's *not* an OOo format, it's the format of
the pre-OOo StarOffice application that was replaced by the UniCode
supporting XML format before OOo got its first release.
For those with concerns that there might be some documents in the old
format that "suddenly" needs to be opened, perhaps a standalone
converter tool from "binfilter" to ODF could be provided. Wait a moment,
that tools already exists: all existing OOo version can be used that way.
Regards,
Mathias
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Am 06.08.2011 19:45, schrieb Dennis E. Hamilton:
> " What does this show? Others behave much worse as we would do. If the
> first AOO release will be the last with binfilters and we assume a
> runnalble/installable state of 5-10 years (depending on OS, unforseeable
> progress, etc...) this will be fine from my POV."
>
> My concern about this rationale is that those of us who see no problem are making a likely irreversible decision that impacts those who do and may not even be aware of what we are doing.
>
> With regard to consumption versus production, I agree that it is easy to stop supporting production when no native consumers are likely to be available any longer and the OpenOffice.org document model evolves to support expanded functionality of further ODF specifications.
>
> So if we propose to retire binfilters, we need some way to make it clear that is happening and what the workarounds are for someone who finds themselves in need. And we definitely need to keep it in a form where someone could revive it at a later time, even if only part of some sort of document-forensics and -recovery/conversion effort rather than integrated into future releases.
Forgot one point: We are not talking about stopping support for
something like PDF/A where readability is guaranteed for years/decades.
We are talking about wildly, unplanned grown old binary filter formats
in the old days of the office where the model was simply streamed out
and in, patched and repaired many times, never documented (for good reason).
> This is not the last time we will need to deal with this (and the same fate could eventually befall the native format currently supported by OpenOffice.org.)
>
> Also, if there are available specifications, whatever their quality, we probably need to see to their preservation as well.
>
> - Dennis
>
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Michael Stahl <ms...@openoffice.org>.
On 06.08.2011 19:45, Dennis E. Hamilton wrote:
> With regard to consumption versus production, I agree that it is easy
> to stop supporting production when no native consumers are likely to
> be available any longer and the OpenOffice.org document model evolves
> to support expanded functionality of further ODF specifications.
the export filters in binfilter were to be disabled for OOo 3.4 anyway,
which should already be the case in OOo 3.4 beta.
> So if we propose to retire binfilters, we need some way to make it
> clear that is happening and what the workarounds are for someone who
> finds themselves in need. And we definitely need to keep it in a
> form where someone could revive it at a later time, even if only part
> of some sort of document-forensics and -recovery/conversion effort
> rather than integrated into future releases.
yes, needs to be added to the release notes.
it will of course be retrievable as part of the first AOOo source
release, and from SVN.
> This is not the last time we will need to deal with this (and the
> same fate could eventually befall the native format currently
> supported by OpenOffice.org.)
you mean OpenOffice.org XML format?
it's implemented in the "xof" library as a rather simple wrapper around
the ODF import/export filter, mostly mangling namespaces and tweaking
some attributes, and shouldn't cause much maintenance effort.
> Also, if there are available specifications, whatever their quality,
> we probably need to see to their preservation as well.
for the binary SO formats it wouldn't surprise me if the specification
were the source code (but that was far before my time, so i wouldn't
know if a real spec exists...).
all the other old formats are foreign anyway.
> - Dennis
another reason why i'd favor removing binfilter ASAP is that i suspect
most of these old filters were written in a less hostile time, so who
knows what security issues the code may have...
good thing binfilter is not installed by default nowadays.
regards,
michael
--
"It's very hard to review carefully this kind of boilerplate code.
Because it's really, really dull. You basically can't pay people
enough to carefully review dull code. We've tried. It does not work.
There's some kind of very strong mental habit that causes people to
just kind of gloss over the repeated bits. [...] So avoiding
boilerplate is key, and ML is very good at that." -- Yaron Minsky
RE: binfilter (was RE: OOO340 to svn)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
" What does this show? Others behave much worse as we would do. If the
first AOO release will be the last with binfilters and we assume a
runnalble/installable state of 5-10 years (depending on OS, unforseeable
progress, etc...) this will be fine from my POV."
My concern about this rationale is that those of us who see no problem are making a likely irreversible decision that impacts those who do and may not even be aware of what we are doing.
With regard to consumption versus production, I agree that it is easy to stop supporting production when no native consumers are likely to be available any longer and the OpenOffice.org document model evolves to support expanded functionality of further ODF specifications.
So if we propose to retire binfilters, we need some way to make it clear that is happening and what the workarounds are for someone who finds themselves in need. And we definitely need to keep it in a form where someone could revive it at a later time, even if only part of some sort of document-forensics and -recovery/conversion effort rather than integrated into future releases.
This is not the last time we will need to deal with this (and the same fate could eventually befall the native format currently supported by OpenOffice.org.)
Also, if there are available specifications, whatever their quality, we probably need to see to their preservation as well.
- Dennis
-----Original Message-----
From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
Sent: Saturday, August 06, 2011 04:57
To: ooo-dev@incubator.apache.org
Subject: Re: binfilter (was RE: OOO340 to svn)
Am 05.08.2011 22:22, schrieb Eric Hoch:
> Hi Armin,
> Am Fri, 05 Aug 2011 19:01:52 +0200 schrieb Armin Le Grand:
>> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>>> The only problem with [2] is that it assumes conversion is
>>> possible/permissible. That is not always the case. Now, I do
>>> not know there is anyone who has that problem and is (or will
>>> soon be) unable to run older software that accesses those
>>> formats, but we do need to be careful in considering this.
>>
>> The current 3.2 version would be the last one to have both, how
>> ling will it be installable and runnable on evolving systems? Can
>> only be guessed, but usually it's another 7-8 years.
>>
>> I have no numbers, but how many people still have files in old
>> formats? With introduction ODF years ago it was preselected as
>> the standard.
>
> I don't know how it is in the country you live in but here in
> Germany documents, especially tax relevant ones from companies,
> must be archived for 10 years or even longer. 2011 minus 10 years
> makes it 2001 and in 2001 there was no ODF.
Germany, too :-)
> At another place I worked before I had a request to open a Works
> 2.0 file which hadn't been used for ages but contained informations
> that years later were needed. At the time of creation of those
> files nobody thought that there would be a time where there would
> be no MS Works that will read old 2.0 formats or that you would
> have even trouble to find a Computer old enough to run MS-DOS or
> Win 95 not to mention the actions it took to get a version of MS
> Works that would read Works 2.0 formats and convert them into a
> format that todays MS Office version would read without totally
> messing up the layout to a point were the file unusable.
What does this show? Others behave much worse as we would do. If the
first AOO release will be the last with binfilters and we assume a
runnalble/installable state of 5-10 years (depending on OS, unforseeable
progress, etc...) this will be fine from my POV.
>> When you load old files, change and safe them you are invited to
>> use ODF for the file save.
>
> That's true but in some cases, see above, you must preserve not
> only the content of the document but also how it looked and the
> digital signature because otherwise there is no proof that you
> didn't edit it. Worst case would be that you convert the document
> with a batch run into ODF, it reads 1000 instead of 100, which you
> don't notice, and convert this in a signed PDF/A. This of course
> can happen also when you use the original StarOffice format but you
> would have eliminated one possible source of errors in the first
> conversion into ODF.
One more reason not to use the most current AOO in five years, but an
older one which is installable and capable of doing the job. I agree
that this would be safer for conversion anyways.
Noone tests binfilter nowadays when during version progress the
underlying libraries (tools, vcl, etc) get changed. This does have
influence on binfilter, but as long as noone using the old formats
stumbles over one (and reports it), it will just stay hidden. Thats what
I meant with that it's even dangerous to keep these last, low-level
dependencies.
> The office was not even as widely
>> spread as it is now before ODF was added as default format, thus
>> potentially much less documents in the old formats were created,
>> compared to ODF.
>>
>> I think something like old file formats have to be deprecated one
>> day, and in my opinion there was a quite long
>> conversion/transition period now. As others already mentioned,
>> binfilter is not even installed by default for 3.2 (if I remember
>> correctly), and I have not seen any complaints about that yet.
>>
>> To All: Does anyone use one of the old binary formats or knows
>> anyone who does actively nowdays? Please answer if you know about
>> something like that, this would be valuable input in this
>> discussion.
>
> Not used actively but needed in order to open old documents which
> cannot be converted into ODF because of the above reason that you
> cannot rule out that you make 100 out of 1000 or the other way
> round.
Use the last version doing both, the first AOO release as it looks. It's
not even released, so there will be some time where it will be installable.
One concrete question: DO you have documents in the old formats or is
this just hypothetical..?
> Eric Hoch
>
Sincerely,
Armin
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/06/2011 02:45 PM, schrieb Eric Hoch:
> Hi Armin,
> Am Sat, 06 Aug 2011 13:56:45 +0200 schrieb Armin Le Grand:
>> Am 05.08.2011 22:22, schrieb Eric Hoch:
>>> Hi Armin,
>>> Am Fri, 05 Aug 2011 19:01:52 +0200 schrieb Armin Le Grand:
>>>> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>>>>> The only problem with [2] is that it assumes conversion is
>>>>> possible/permissible. That is not always the case. Now, I do
>>>>> not know there is anyone who has that problem and is (or will
>>>>> soon be) unable to run older software that accesses those
>>>>> formats, but we do need to be careful in considering this.
>>>>
>>>> The current 3.2 version would be the last one to have both, how
>>>> ling will it be installable and runnable on evolving systems? Can
>>>> only be guessed, but usually it's another 7-8 years.
>>>>
>>>> I have no numbers, but how many people still have files in old
>>>> formats? With introduction ODF years ago it was preselected as
>>>> the standard.
>>>
>>> I don't know how it is in the country you live in but here in
>>> Germany documents, especially tax relevant ones from companies,
>>> must be archived for 10 years or even longer. 2011 minus 10 years
>>> makes it 2001 and in 2001 there was no ODF.
>>
>> Germany, too :-)
>
> :-)
>
>>>> I think something like old file formats have to be deprecated one
>>>> day, and in my opinion there was a quite long
>>>> conversion/transition period now. As others already mentioned,
>>>> binfilter is not even installed by default for 3.2 (if I remember
>>>> correctly), and I have not seen any complaints about that yet.
>
> Neither do I but that doesn't meant that there aren't any out
> there.
>
>
>>>> To All: Does anyone use one of the old binary formats or knows
>>>> anyone who does actively nowdays? Please answer if you know about
>>>> something like that, this would be valuable input in this
>>>> discussion.
>>>
>>> Not used actively but needed in order to open old documents which
>>> cannot be converted into ODF because of the above reason that you
>>> cannot rule out that you make 100 out of 1000 or the other way
>>> round.
>>
>> Use the last version doing both, the first AOO release as it
>> looks. It's not even released, so there will be some time where
>> it will be installable.
>
> Sounds good. We need a clean statement that this will be the last
> version coming with import-/exportfilters for the following
> formats. Please make sure that you convert documents of need into a
> new format or archive them probably into PDF/A, etc... This should
> be written so that non-tech users understand it.
OK, I've setup a reminder to write such a text:
https://cwiki.apache.org/confluence/display/OOOUSERS/Release-PPMC-Plan
Marcus
>> One concrete question: DO you have documents in the old formats
>> or is this just hypothetical..?
>
> Yes I have documents in the old format but they are privat, not tax
> related and already to 99% redone in the new ODF Format. The most
> important document in the old format I have is my Diplomarbeit
> which for whatever reason converts badly into the new ODF format. I
> think I'll need to spend a day or two on the reformatting of the
> document.
>
> I also assume that come the ongoing inspection of documents and
> used software at my new job it is possible to find documents
> needing binfilter, if for whatever reason someone used StarOffice
> instead of MS Office.
>
> Eric
Re: binfilter (was RE: OOO340 to svn)
Posted by Eric Hoch <er...@gmx.de>.
Hi Armin,
Am Sat, 06 Aug 2011 13:56:45 +0200 schrieb Armin Le Grand:
> Am 05.08.2011 22:22, schrieb Eric Hoch:
>> Hi Armin,
>> Am Fri, 05 Aug 2011 19:01:52 +0200 schrieb Armin Le Grand:
>>> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>>>> The only problem with [2] is that it assumes conversion is
>>>> possible/permissible. That is not always the case. Now, I do
>>>> not know there is anyone who has that problem and is (or will
>>>> soon be) unable to run older software that accesses those
>>>> formats, but we do need to be careful in considering this.
>>>
>>> The current 3.2 version would be the last one to have both, how
>>> ling will it be installable and runnable on evolving systems? Can
>>> only be guessed, but usually it's another 7-8 years.
>>>
>>> I have no numbers, but how many people still have files in old
>>> formats? With introduction ODF years ago it was preselected as
>>> the standard.
>>
>> I don't know how it is in the country you live in but here in
>> Germany documents, especially tax relevant ones from companies,
>> must be archived for 10 years or even longer. 2011 minus 10 years
>> makes it 2001 and in 2001 there was no ODF.
>
> Germany, too :-)
:-)
>>> I think something like old file formats have to be deprecated one
>>> day, and in my opinion there was a quite long
>>> conversion/transition period now. As others already mentioned,
>>> binfilter is not even installed by default for 3.2 (if I remember
>>> correctly), and I have not seen any complaints about that yet.
Neither do I but that doesn't meant that there aren't any out
there.
>>> To All: Does anyone use one of the old binary formats or knows
>>> anyone who does actively nowdays? Please answer if you know about
>>> something like that, this would be valuable input in this
>>> discussion.
>>
>> Not used actively but needed in order to open old documents which
>> cannot be converted into ODF because of the above reason that you
>> cannot rule out that you make 100 out of 1000 or the other way
>> round.
>
> Use the last version doing both, the first AOO release as it
> looks. It's not even released, so there will be some time where
> it will be installable.
Sounds good. We need a clean statement that this will be the last
version coming with import-/exportfilters for the following
formats. Please make sure that you convert documents of need into a
new format or archive them probably into PDF/A, etc... This should
be written so that non-tech users understand it.
> One concrete question: DO you have documents in the old formats
> or is this just hypothetical..?
Yes I have documents in the old format but they are privat, not tax
related and already to 99% redone in the new ODF Format. The most
important document in the old format I have is my Diplomarbeit
which for whatever reason converts badly into the new ODF format. I
think I'll need to spend a day or two on the reformatting of the
document.
I also assume that come the ongoing inspection of documents and
used software at my new job it is possible to find documents
needing binfilter, if for whatever reason someone used StarOffice
instead of MS Office.
Eric
--
## de.OpenOffice.org - Office für MacOS X, Linux, Solaris & Windows
## Openoffice.org - ich steck mit drin!
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Am 05.08.2011 22:22, schrieb Eric Hoch:
> Hi Armin,
> Am Fri, 05 Aug 2011 19:01:52 +0200 schrieb Armin Le Grand:
>> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>>> The only problem with [2] is that it assumes conversion is
>>> possible/permissible. That is not always the case. Now, I do
>>> not know there is anyone who has that problem and is (or will
>>> soon be) unable to run older software that accesses those
>>> formats, but we do need to be careful in considering this.
>>
>> The current 3.2 version would be the last one to have both, how
>> ling will it be installable and runnable on evolving systems? Can
>> only be guessed, but usually it's another 7-8 years.
>>
>> I have no numbers, but how many people still have files in old
>> formats? With introduction ODF years ago it was preselected as
>> the standard.
>
> I don't know how it is in the country you live in but here in
> Germany documents, especially tax relevant ones from companies,
> must be archived for 10 years or even longer. 2011 minus 10 years
> makes it 2001 and in 2001 there was no ODF.
Germany, too :-)
> At another place I worked before I had a request to open a Works
> 2.0 file which hadn't been used for ages but contained informations
> that years later were needed. At the time of creation of those
> files nobody thought that there would be a time where there would
> be no MS Works that will read old 2.0 formats or that you would
> have even trouble to find a Computer old enough to run MS-DOS or
> Win 95 not to mention the actions it took to get a version of MS
> Works that would read Works 2.0 formats and convert them into a
> format that todays MS Office version would read without totally
> messing up the layout to a point were the file unusable.
What does this show? Others behave much worse as we would do. If the
first AOO release will be the last with binfilters and we assume a
runnalble/installable state of 5-10 years (depending on OS, unforseeable
progress, etc...) this will be fine from my POV.
>> When you load old files, change and safe them you are invited to
>> use ODF for the file save.
>
> That's true but in some cases, see above, you must preserve not
> only the content of the document but also how it looked and the
> digital signature because otherwise there is no proof that you
> didn't edit it. Worst case would be that you convert the document
> with a batch run into ODF, it reads 1000 instead of 100, which you
> don't notice, and convert this in a signed PDF/A. This of course
> can happen also when you use the original StarOffice format but you
> would have eliminated one possible source of errors in the first
> conversion into ODF.
One more reason not to use the most current AOO in five years, but an
older one which is installable and capable of doing the job. I agree
that this would be safer for conversion anyways.
Noone tests binfilter nowadays when during version progress the
underlying libraries (tools, vcl, etc) get changed. This does have
influence on binfilter, but as long as noone using the old formats
stumbles over one (and reports it), it will just stay hidden. Thats what
I meant with that it's even dangerous to keep these last, low-level
dependencies.
> The office was not even as widely
>> spread as it is now before ODF was added as default format, thus
>> potentially much less documents in the old formats were created,
>> compared to ODF.
>>
>> I think something like old file formats have to be deprecated one
>> day, and in my opinion there was a quite long
>> conversion/transition period now. As others already mentioned,
>> binfilter is not even installed by default for 3.2 (if I remember
>> correctly), and I have not seen any complaints about that yet.
>>
>> To All: Does anyone use one of the old binary formats or knows
>> anyone who does actively nowdays? Please answer if you know about
>> something like that, this would be valuable input in this
>> discussion.
>
> Not used actively but needed in order to open old documents which
> cannot be converted into ODF because of the above reason that you
> cannot rule out that you make 100 out of 1000 or the other way
> round.
Use the last version doing both, the first AOO release as it looks. It's
not even released, so there will be some time where it will be installable.
One concrete question: DO you have documents in the old formats or is
this just hypothetical..?
> Eric Hoch
>
Sincerely,
Armin
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Eric Hoch <er...@gmx.de>.
Hi Armin,
Am Fri, 05 Aug 2011 19:01:52 +0200 schrieb Armin Le Grand:
> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>> The only problem with [2] is that it assumes conversion is
>> possible/permissible. That is not always the case. Now, I do
>> not know there is anyone who has that problem and is (or will
>> soon be) unable to run older software that accesses those
>> formats, but we do need to be careful in considering this.
>
> The current 3.2 version would be the last one to have both, how
> ling will it be installable and runnable on evolving systems? Can
> only be guessed, but usually it's another 7-8 years.
>
> I have no numbers, but how many people still have files in old
> formats? With introduction ODF years ago it was preselected as
> the standard.
I don't know how it is in the country you live in but here in
Germany documents, especially tax relevant ones from companies,
must be archived for 10 years or even longer. 2011 minus 10 years
makes it 2001 and in 2001 there was no ODF.
At another place I worked before I had a request to open a Works
2.0 file which hadn't been used for ages but contained informations
that years later were needed. At the time of creation of those
files nobody thought that there would be a time where there would
be no MS Works that will read old 2.0 formats or that you would
have even trouble to find a Computer old enough to run MS-DOS or
Win 95 not to mention the actions it took to get a version of MS
Works that would read Works 2.0 formats and convert them into a
format that todays MS Office version would read without totally
messing up the layout to a point were the file unusable.
> When you load old files, change and safe them you are invited to
> use ODF for the file save.
That's true but in some cases, see above, you must preserve not
only the content of the document but also how it looked and the
digital signature because otherwise there is no proof that you
didn't edit it. Worst case would be that you convert the document
with a batch run into ODF, it reads 1000 instead of 100, which you
don't notice, and convert this in a signed PDF/A. This of course
can happen also when you use the original StarOffice format but you
would have eliminated one possible source of errors in the first
conversion into ODF.
The office was not even as widely
> spread as it is now before ODF was added as default format, thus
> potentially much less documents in the old formats were created,
> compared to ODF.
>
> I think something like old file formats have to be deprecated one
> day, and in my opinion there was a quite long
> conversion/transition period now. As others already mentioned,
> binfilter is not even installed by default for 3.2 (if I remember
> correctly), and I have not seen any complaints about that yet.
>
> To All: Does anyone use one of the old binary formats or knows
> anyone who does actively nowdays? Please answer if you know about
> something like that, this would be valuable input in this
> discussion.
Not used actively but needed in order to open old documents which
cannot be converted into ODF because of the above reason that you
cannot rule out that you make 100 out of 1000 or the other way
round.
Eric Hoch
--
## de.OpenOffice.org - Office für MacOS X, Linux, Solaris & Windows
## Openoffice.org - ich steck mit drin!
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Am 05.08.2011 19:44, schrieb Marcus (OOo):
> I hope that we still agree to keep the binfilters with our first Apache
> release. Otherwise we would deplay it more than IMHO necessary.
Correct, full agreement. Sorry to have not mentioned that, but of course
for the first release it should stay added. Not sure about the current
state, seems as if it is installed optional with default to false. I'll
need to check that ASASAA (As Soon As Sources Are Available :-))
>
> After the first is done we can remove them for the 2nd official Apache
> version. While we do many dev builds on the way (hopefully, like it was
> with OOo) we can see if there are more problems that we have to take
> into account.
Agreed.
> In parallel we can make an announcement that the next version has
> a) only support for importing the old binary file formats
> - or -
> b) no support for import and export.
> Depends on what we want.
Agreed. I would just announce that it's the last version with binary
filters, not really a neccesary to forbid writing from my POV.
Regards,
Armin
> Marcus
>
>
>
> Am 08/05/2011 07:01 PM, schrieb Armin Le Grand:
>> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>>> The only problem with [2] is that it assumes conversion is
>>> possible/permissible. That is not always the case. Now, I do not know
>>> there is anyone who has that problem and is (or will soon be) unable
>>> to run older software that accesses those formats, but we do need to
>>> be careful in considering this.
>>
>> The current 3.2 version would be the last one to have both, how ling
>> will it be installable and runnable on evolving systems? Can only be
>> guessed, but usually it's another 7-8 years.
>>
>> I have no numbers, but how many people still have files in old formats?
>> With introduction ODF years ago it was preselected as the standard.
>>
>> When you load old files, change and safe them you are invited to use ODF
>> for the file save. The office was not even as widely spread as it is now
>> before ODF was added as default format, thus potentially much less
>> documents in the old formats were created, compared to ODF.
>>
>> I think something like old file formats have to be deprecated one day,
>> and in my opinion there was a quite long conversion/transition period
>> now. As others already mentioned, binfilter is not even installed by
>> default for 3.2 (if I remember correctly), and I have not seen any
>> complaints about that yet.
>>
>> To All: Does anyone use one of the old binary formats or knows anyone
>> who does actively nowdays? Please answer if you know about something
>> like that, this would be valuable input in this discussion.
>>
>> Regards,
>> Armin
>>
>>> In the future, this problem will become more likely because conversion
>>> is prevented by technical means, not just an usage case (e.g., when a
>>> document is digitally-signed and the signature must be preserved).
>>>
>>>
>>> - Dennis
>>>
>>> -----Original Message-----
>>> From: Armin Le Grand
>>> [mailto:Armin.Le.Grand@me.com]
>>> Sent: Friday, August 05, 2011 04:34
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: binfilter (was RE: OOO340 to svn)
>>>
>>> Hi *,
>>>
>>> Binfilter can pretty simply be linked statically against the remaining
>>> dependencies (tools and below) and just stay there as a binary module.
>>> It already is a UNO API based module, so having binfilter or not is just
>>> a matter of copying the binaries or not during installation, plus maybe
>>> some finetuning.
>>>
>>> My initial suggestion was anyways to not add it as a module, but keep it
>>> static on the version it was added in the past; being indirectly changed
>>> by changing the below modules for other purposes is theoretically even
>>> dangerous and may introduce errors.
>>>
>>> Seen from today I see no reason at all to keep it; there are about 20
>>> versions of OOo/other derivates out there which support it and thus
>>> support converting documents. Everyone who still has old docs (few after
>>> 7-8 years I guess) is able to get a version before removal, install it
>>> and convert those docs.
>>>
>>> As discussed above, there are two possibilities (well, three, if we keep
>>> it as it is):
>>>
>>> [1] Do the not too difficult step of making binfilter independent from
>>> the rest by statically linking, keep it on the current version. Use the
>>> resulting binary module for future versions.
>>>
>>> [2] Completely remove it and refer any complaints from people which were
>>> not able to move to the new file formtats in the last 7-8 years to the
>>> countless versions which are capable to do the conversion
>>>
>>> Thus I clearly suggest to do [2] now, enough ressources (memory,
>>> bandwidth, built time, ...) spent on it. Let's use the chance to cut
>>> some old burdens.
>>>
>>> BTW: Fo the interested I already mentioned some facts about it's history
>>> here [news://news.gmane.org:119/iufajg$339$1@dough.gmane.org]
>>>
>>> Am 03.08.2011 21:17, schrieb Mathias Bauer:
>>>> On 03.08.2011 20:25, Dennis E. Hamilton wrote:
>>>>
>>>>> What I managed to glean from the LibreOffice discussion lists is that
>>>>> binfilter will be separately installable but probably not taken to
>>>>> end-of-life. (As platforms change, it may be necessary to make new
>>>>> builds of it.)
>>>>
>>>> Binfilter already is installable separately - on Windows it's an option
>>>> in the setup that you can disable (and AFAIK it is disabled by
>>>> default).
>>>> What you probably mean is that they are discussing to make binfilter a
>>>> component that is compatible cross versions and so does not need to be
>>>> installed each time when a new version of the office program is
>>>> installed.
>>>>
>>>> As this currently fails due to some dependencies between binfilter and
>>>> "the rest of the office" that are not stable enough and might change in
>>>> every release, this ends up in the discussion you mentioned:
>>>>
>>>>> There is also discussion about moving some annoying dependencies into
>>>>> the binfilter (and other converter) branches in some case, so they
>>>>> don't have to be maintained in sync with the main distro.
>>>>
>>>> That's nothing new and this has happened in the past already in several
>>>> cases. I did that by myself on several occasions. But this approach is
>>>> doomed to fail in at least two cases: GraphicObjects and vcl. At least
>>>> it would require to refactor large parts of the binfilter code to be
>>>> able to remove these dependencies. There are much more better places
>>>> where time could be invested better. [Remark: IMHO the GraphicObject
>>>> problem should be solvable with moderate effort, I doubt that this is
>>>> the case for vcl.]
>>>>
>>>> But maybe this is just a problem because people want to see a problem
>>>> in it.
>>>>
>>>> Though in theory binfilter creates some maintenance effort due to its
>>>> remaining dependencies on other code, I can't remember a lot of
>>>> necessary work on binfilter caused by these dependencies in the last
>>>> years. In the past we already went the "remove annoying dependencies"
>>>> road for binfilter: each time when a developer made huge changes in a
>>>> module that would require larger code adjustments in binfilter, the
>>>> module that was going to be changed was copied before the change and
>>>> the
>>>> unmodified copy was moved into binfilter (and hopefully ;-) stripped
>>>> from all code not used in binfilter later). As I wrote, this doesn't
>>>> work for the GraphicObject and vcl, but we already used it for most of
>>>> the bigger modules with a lot of code changes, so I don't expect a lot
>>>> of room for improvement here.
>>>>
>>>> It should be mentioned that this approach only optimized the work
>>>> from a
>>>> maintencance cost POV, but it made things worse in other areas:
>>>> binfilter becomes bigger each time when a copied module was added,
>>>> increasing both build time and size of the installation set. And even
>>>> the optimization for maintenance cost is incomplete as the resulting
>>>> code duplication will require duplicated work in the future at least in
>>>> case security leaks are found (been there, done that ...).
>>>>
>>>>> There is also a thrust to make converters more cleanly-separated and
>>>>> having the plugin APIs work successfully for them. Again, this is
>>>>> the gist of it. It doesn't seem too far from ideas that have been
>>>>> floated around here, though.
>>>>
>>>> I'm afraid that talking about stuff like this without actually knowing
>>>> the code will at best create confusion. So all I will say about that
>>>> here is:
>>>>
>>>> We don't have converters, we have filters. And some of them are cleanly
>>>> separated already, some aren't. As long as the latter aren't going
>>>> to be
>>>> reimplemented anyway, there wouldn't be much sense in investing time
>>>> into improving their modularity.
>>>>
>>>> Is binfilter the next "bike shed" we are targetting?
>>>>
>>>> Regards,
>>>> Mathias
>>>>
>>> --
>>> ALG
>>>
>>>
>>
>> --
>> ALG
>
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
I hope that we still agree to keep the binfilters with our first Apache
release. Otherwise we would deplay it more than IMHO necessary.
After the first is done we can remove them for the 2nd official Apache
version. While we do many dev builds on the way (hopefully, like it was
with OOo) we can see if there are more problems that we have to take
into account.
In parallel we can make an announcement that the next version has
a) only support for importing the old binary file formats
- or -
b) no support for import and export.
Depends on what we want.
Marcus
Am 08/05/2011 07:01 PM, schrieb Armin Le Grand:
> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>> The only problem with [2] is that it assumes conversion is
>> possible/permissible. That is not always the case. Now, I do not know
>> there is anyone who has that problem and is (or will soon be) unable
>> to run older software that accesses those formats, but we do need to
>> be careful in considering this.
>
> The current 3.2 version would be the last one to have both, how ling
> will it be installable and runnable on evolving systems? Can only be
> guessed, but usually it's another 7-8 years.
>
> I have no numbers, but how many people still have files in old formats?
> With introduction ODF years ago it was preselected as the standard.
>
> When you load old files, change and safe them you are invited to use ODF
> for the file save. The office was not even as widely spread as it is now
> before ODF was added as default format, thus potentially much less
> documents in the old formats were created, compared to ODF.
>
> I think something like old file formats have to be deprecated one day,
> and in my opinion there was a quite long conversion/transition period
> now. As others already mentioned, binfilter is not even installed by
> default for 3.2 (if I remember correctly), and I have not seen any
> complaints about that yet.
>
> To All: Does anyone use one of the old binary formats or knows anyone
> who does actively nowdays? Please answer if you know about something
> like that, this would be valuable input in this discussion.
>
> Regards,
> Armin
>
>> In the future, this problem will become more likely because conversion
>> is prevented by technical means, not just an usage case (e.g., when a
>> document is digitally-signed and the signature must be preserved).
>>
>>
>> - Dennis
>>
>> -----Original Message-----
>> From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
>> Sent: Friday, August 05, 2011 04:34
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: binfilter (was RE: OOO340 to svn)
>>
>> Hi *,
>>
>> Binfilter can pretty simply be linked statically against the remaining
>> dependencies (tools and below) and just stay there as a binary module.
>> It already is a UNO API based module, so having binfilter or not is just
>> a matter of copying the binaries or not during installation, plus maybe
>> some finetuning.
>>
>> My initial suggestion was anyways to not add it as a module, but keep it
>> static on the version it was added in the past; being indirectly changed
>> by changing the below modules for other purposes is theoretically even
>> dangerous and may introduce errors.
>>
>> Seen from today I see no reason at all to keep it; there are about 20
>> versions of OOo/other derivates out there which support it and thus
>> support converting documents. Everyone who still has old docs (few after
>> 7-8 years I guess) is able to get a version before removal, install it
>> and convert those docs.
>>
>> As discussed above, there are two possibilities (well, three, if we keep
>> it as it is):
>>
>> [1] Do the not too difficult step of making binfilter independent from
>> the rest by statically linking, keep it on the current version. Use the
>> resulting binary module for future versions.
>>
>> [2] Completely remove it and refer any complaints from people which were
>> not able to move to the new file formtats in the last 7-8 years to the
>> countless versions which are capable to do the conversion
>>
>> Thus I clearly suggest to do [2] now, enough ressources (memory,
>> bandwidth, built time, ...) spent on it. Let's use the chance to cut
>> some old burdens.
>>
>> BTW: Fo the interested I already mentioned some facts about it's history
>> here [news://news.gmane.org:119/iufajg$339$1@dough.gmane.org]
>>
>> Am 03.08.2011 21:17, schrieb Mathias Bauer:
>>> On 03.08.2011 20:25, Dennis E. Hamilton wrote:
>>>
>>>> What I managed to glean from the LibreOffice discussion lists is that
>>>> binfilter will be separately installable but probably not taken to
>>>> end-of-life. (As platforms change, it may be necessary to make new
>>>> builds of it.)
>>>
>>> Binfilter already is installable separately - on Windows it's an option
>>> in the setup that you can disable (and AFAIK it is disabled by default).
>>> What you probably mean is that they are discussing to make binfilter a
>>> component that is compatible cross versions and so does not need to be
>>> installed each time when a new version of the office program is
>>> installed.
>>>
>>> As this currently fails due to some dependencies between binfilter and
>>> "the rest of the office" that are not stable enough and might change in
>>> every release, this ends up in the discussion you mentioned:
>>>
>>>> There is also discussion about moving some annoying dependencies into
>>>> the binfilter (and other converter) branches in some case, so they
>>>> don't have to be maintained in sync with the main distro.
>>>
>>> That's nothing new and this has happened in the past already in several
>>> cases. I did that by myself on several occasions. But this approach is
>>> doomed to fail in at least two cases: GraphicObjects and vcl. At least
>>> it would require to refactor large parts of the binfilter code to be
>>> able to remove these dependencies. There are much more better places
>>> where time could be invested better. [Remark: IMHO the GraphicObject
>>> problem should be solvable with moderate effort, I doubt that this is
>>> the case for vcl.]
>>>
>>> But maybe this is just a problem because people want to see a problem
>>> in it.
>>>
>>> Though in theory binfilter creates some maintenance effort due to its
>>> remaining dependencies on other code, I can't remember a lot of
>>> necessary work on binfilter caused by these dependencies in the last
>>> years. In the past we already went the "remove annoying dependencies"
>>> road for binfilter: each time when a developer made huge changes in a
>>> module that would require larger code adjustments in binfilter, the
>>> module that was going to be changed was copied before the change and the
>>> unmodified copy was moved into binfilter (and hopefully ;-) stripped
>>> from all code not used in binfilter later). As I wrote, this doesn't
>>> work for the GraphicObject and vcl, but we already used it for most of
>>> the bigger modules with a lot of code changes, so I don't expect a lot
>>> of room for improvement here.
>>>
>>> It should be mentioned that this approach only optimized the work from a
>>> maintencance cost POV, but it made things worse in other areas:
>>> binfilter becomes bigger each time when a copied module was added,
>>> increasing both build time and size of the installation set. And even
>>> the optimization for maintenance cost is incomplete as the resulting
>>> code duplication will require duplicated work in the future at least in
>>> case security leaks are found (been there, done that ...).
>>>
>>>> There is also a thrust to make converters more cleanly-separated and
>>>> having the plugin APIs work successfully for them. Again, this is
>>>> the gist of it. It doesn't seem too far from ideas that have been
>>>> floated around here, though.
>>>
>>> I'm afraid that talking about stuff like this without actually knowing
>>> the code will at best create confusion. So all I will say about that
>>> here is:
>>>
>>> We don't have converters, we have filters. And some of them are cleanly
>>> separated already, some aren't. As long as the latter aren't going to be
>>> reimplemented anyway, there wouldn't be much sense in investing time
>>> into improving their modularity.
>>>
>>> Is binfilter the next "bike shed" we are targetting?
>>>
>>> Regards,
>>> Mathias
>>>
>> --
>> ALG
>>
>>
>
> --
> ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
> The only problem with [2] is that it assumes conversion is possible/permissible. That is not always the case. Now, I do not know there is anyone who has that problem and is (or will soon be) unable to run older software that accesses those formats, but we do need to be careful in considering this.
The current 3.2 version would be the last one to have both, how ling
will it be installable and runnable on evolving systems? Can only be
guessed, but usually it's another 7-8 years.
I have no numbers, but how many people still have files in old formats?
With introduction ODF years ago it was preselected as the standard.
When you load old files, change and safe them you are invited to use ODF
for the file save. The office was not even as widely spread as it is now
before ODF was added as default format, thus potentially much less
documents in the old formats were created, compared to ODF.
I think something like old file formats have to be deprecated one day,
and in my opinion there was a quite long conversion/transition period
now. As others already mentioned, binfilter is not even installed by
default for 3.2 (if I remember correctly), and I have not seen any
complaints about that yet.
To All: Does anyone use one of the old binary formats or knows anyone
who does actively nowdays? Please answer if you know about something
like that, this would be valuable input in this discussion.
Regards,
Armin
> In the future, this problem will become more likely because conversion is prevented by technical means, not just an usage case (e.g., when a document is digitally-signed and the signature must be preserved).
>
>
> - Dennis
>
> -----Original Message-----
> From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
> Sent: Friday, August 05, 2011 04:34
> To: ooo-dev@incubator.apache.org
> Subject: Re: binfilter (was RE: OOO340 to svn)
>
> Hi *,
>
> Binfilter can pretty simply be linked statically against the remaining
> dependencies (tools and below) and just stay there as a binary module.
> It already is a UNO API based module, so having binfilter or not is just
> a matter of copying the binaries or not during installation, plus maybe
> some finetuning.
>
> My initial suggestion was anyways to not add it as a module, but keep it
> static on the version it was added in the past; being indirectly changed
> by changing the below modules for other purposes is theoretically even
> dangerous and may introduce errors.
>
> Seen from today I see no reason at all to keep it; there are about 20
> versions of OOo/other derivates out there which support it and thus
> support converting documents. Everyone who still has old docs (few after
> 7-8 years I guess) is able to get a version before removal, install it
> and convert those docs.
>
> As discussed above, there are two possibilities (well, three, if we keep
> it as it is):
>
> [1] Do the not too difficult step of making binfilter independent from
> the rest by statically linking, keep it on the current version. Use the
> resulting binary module for future versions.
>
> [2] Completely remove it and refer any complaints from people which were
> not able to move to the new file formtats in the last 7-8 years to the
> countless versions which are capable to do the conversion
>
> Thus I clearly suggest to do [2] now, enough ressources (memory,
> bandwidth, built time, ...) spent on it. Let's use the chance to cut
> some old burdens.
>
> BTW: Fo the interested I already mentioned some facts about it's history
> here [news://news.gmane.org:119/iufajg$339$1@dough.gmane.org]
>
> Am 03.08.2011 21:17, schrieb Mathias Bauer:
>> On 03.08.2011 20:25, Dennis E. Hamilton wrote:
>>
>>> What I managed to glean from the LibreOffice discussion lists is that
>>> binfilter will be separately installable but probably not taken to
>>> end-of-life. (As platforms change, it may be necessary to make new
>>> builds of it.)
>>
>> Binfilter already is installable separately - on Windows it's an option
>> in the setup that you can disable (and AFAIK it is disabled by default).
>> What you probably mean is that they are discussing to make binfilter a
>> component that is compatible cross versions and so does not need to be
>> installed each time when a new version of the office program is installed.
>>
>> As this currently fails due to some dependencies between binfilter and
>> "the rest of the office" that are not stable enough and might change in
>> every release, this ends up in the discussion you mentioned:
>>
>>> There is also discussion about moving some annoying dependencies into
>>> the binfilter (and other converter) branches in some case, so they
>>> don't have to be maintained in sync with the main distro.
>>
>> That's nothing new and this has happened in the past already in several
>> cases. I did that by myself on several occasions. But this approach is
>> doomed to fail in at least two cases: GraphicObjects and vcl. At least
>> it would require to refactor large parts of the binfilter code to be
>> able to remove these dependencies. There are much more better places
>> where time could be invested better. [Remark: IMHO the GraphicObject
>> problem should be solvable with moderate effort, I doubt that this is
>> the case for vcl.]
>>
>> But maybe this is just a problem because people want to see a problem in it.
>>
>> Though in theory binfilter creates some maintenance effort due to its
>> remaining dependencies on other code, I can't remember a lot of
>> necessary work on binfilter caused by these dependencies in the last
>> years. In the past we already went the "remove annoying dependencies"
>> road for binfilter: each time when a developer made huge changes in a
>> module that would require larger code adjustments in binfilter, the
>> module that was going to be changed was copied before the change and the
>> unmodified copy was moved into binfilter (and hopefully ;-) stripped
>> from all code not used in binfilter later). As I wrote, this doesn't
>> work for the GraphicObject and vcl, but we already used it for most of
>> the bigger modules with a lot of code changes, so I don't expect a lot
>> of room for improvement here.
>>
>> It should be mentioned that this approach only optimized the work from a
>> maintencance cost POV, but it made things worse in other areas:
>> binfilter becomes bigger each time when a copied module was added,
>> increasing both build time and size of the installation set. And even
>> the optimization for maintenance cost is incomplete as the resulting
>> code duplication will require duplicated work in the future at least in
>> case security leaks are found (been there, done that ...).
>>
>>> There is also a thrust to make converters more cleanly-separated and
>>> having the plugin APIs work successfully for them. Again, this is
>>> the gist of it. It doesn't seem too far from ideas that have been
>>> floated around here, though.
>>
>> I'm afraid that talking about stuff like this without actually knowing
>> the code will at best create confusion. So all I will say about that
>> here is:
>>
>> We don't have converters, we have filters. And some of them are cleanly
>> separated already, some aren't. As long as the latter aren't going to be
>> reimplemented anyway, there wouldn't be much sense in investing time
>> into improving their modularity.
>>
>> Is binfilter the next "bike shed" we are targetting?
>>
>> Regards,
>> Mathias
>>
> --
> ALG
>
>
--
ALG
RE: binfilter (was RE: OOO340 to svn)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The only problem with [2] is that it assumes conversion is possible/permissible. That is not always the case. Now, I do not know there is anyone who has that problem and is (or will soon be) unable to run older software that accesses those formats, but we do need to be careful in considering this.
In the future, this problem will become more likely because conversion is prevented by technical means, not just an usage case (e.g., when a document is digitally-signed and the signature must be preserved).
- Dennis
-----Original Message-----
From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]
Sent: Friday, August 05, 2011 04:34
To: ooo-dev@incubator.apache.org
Subject: Re: binfilter (was RE: OOO340 to svn)
Hi *,
Binfilter can pretty simply be linked statically against the remaining
dependencies (tools and below) and just stay there as a binary module.
It already is a UNO API based module, so having binfilter or not is just
a matter of copying the binaries or not during installation, plus maybe
some finetuning.
My initial suggestion was anyways to not add it as a module, but keep it
static on the version it was added in the past; being indirectly changed
by changing the below modules for other purposes is theoretically even
dangerous and may introduce errors.
Seen from today I see no reason at all to keep it; there are about 20
versions of OOo/other derivates out there which support it and thus
support converting documents. Everyone who still has old docs (few after
7-8 years I guess) is able to get a version before removal, install it
and convert those docs.
As discussed above, there are two possibilities (well, three, if we keep
it as it is):
[1] Do the not too difficult step of making binfilter independent from
the rest by statically linking, keep it on the current version. Use the
resulting binary module for future versions.
[2] Completely remove it and refer any complaints from people which were
not able to move to the new file formtats in the last 7-8 years to the
countless versions which are capable to do the conversion
Thus I clearly suggest to do [2] now, enough ressources (memory,
bandwidth, built time, ...) spent on it. Let's use the chance to cut
some old burdens.
BTW: Fo the interested I already mentioned some facts about it's history
here [news://news.gmane.org:119/iufajg$339$1@dough.gmane.org]
Am 03.08.2011 21:17, schrieb Mathias Bauer:
> On 03.08.2011 20:25, Dennis E. Hamilton wrote:
>
>> What I managed to glean from the LibreOffice discussion lists is that
>> binfilter will be separately installable but probably not taken to
>> end-of-life. (As platforms change, it may be necessary to make new
>> builds of it.)
>
> Binfilter already is installable separately - on Windows it's an option
> in the setup that you can disable (and AFAIK it is disabled by default).
> What you probably mean is that they are discussing to make binfilter a
> component that is compatible cross versions and so does not need to be
> installed each time when a new version of the office program is installed.
>
> As this currently fails due to some dependencies between binfilter and
> "the rest of the office" that are not stable enough and might change in
> every release, this ends up in the discussion you mentioned:
>
>> There is also discussion about moving some annoying dependencies into
>> the binfilter (and other converter) branches in some case, so they
>> don't have to be maintained in sync with the main distro.
>
> That's nothing new and this has happened in the past already in several
> cases. I did that by myself on several occasions. But this approach is
> doomed to fail in at least two cases: GraphicObjects and vcl. At least
> it would require to refactor large parts of the binfilter code to be
> able to remove these dependencies. There are much more better places
> where time could be invested better. [Remark: IMHO the GraphicObject
> problem should be solvable with moderate effort, I doubt that this is
> the case for vcl.]
>
> But maybe this is just a problem because people want to see a problem in it.
>
> Though in theory binfilter creates some maintenance effort due to its
> remaining dependencies on other code, I can't remember a lot of
> necessary work on binfilter caused by these dependencies in the last
> years. In the past we already went the "remove annoying dependencies"
> road for binfilter: each time when a developer made huge changes in a
> module that would require larger code adjustments in binfilter, the
> module that was going to be changed was copied before the change and the
> unmodified copy was moved into binfilter (and hopefully ;-) stripped
> from all code not used in binfilter later). As I wrote, this doesn't
> work for the GraphicObject and vcl, but we already used it for most of
> the bigger modules with a lot of code changes, so I don't expect a lot
> of room for improvement here.
>
> It should be mentioned that this approach only optimized the work from a
> maintencance cost POV, but it made things worse in other areas:
> binfilter becomes bigger each time when a copied module was added,
> increasing both build time and size of the installation set. And even
> the optimization for maintenance cost is incomplete as the resulting
> code duplication will require duplicated work in the future at least in
> case security leaks are found (been there, done that ...).
>
>> There is also a thrust to make converters more cleanly-separated and
>> having the plugin APIs work successfully for them. Again, this is
>> the gist of it. It doesn't seem too far from ideas that have been
>> floated around here, though.
>
> I'm afraid that talking about stuff like this without actually knowing
> the code will at best create confusion. So all I will say about that
> here is:
>
> We don't have converters, we have filters. And some of them are cleanly
> separated already, some aren't. As long as the latter aren't going to be
> reimplemented anyway, there wouldn't be much sense in investing time
> into improving their modularity.
>
> Is binfilter the next "bike shed" we are targetting?
>
> Regards,
> Mathias
>
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Am 05.08.2011 18:15, schrieb Mathias Bauer:
> On 05.08.2011 17:21, Armin Le Grand wrote:
>
>> Hi Mathias,
>>
>> Am 05.08.2011 16:25, schrieb Mathias Bauer:
>>> On 05.08.2011 13:33, Armin Le Grand wrote:
>>>
>>>> [1] Do the not too difficult step of making binfilter independent from
>>>> the rest by statically linking, keep it on the current version. Use the
>>>> resulting binary module for future versions.
>>>
>>> As long as binfilter runs in the same process, you can't link it
>>> statically against vcl.
>>
>> Yes, right. Thanks for the hint. Thus, the remaining missing stuff has
>> to be stripped and added in the binfilter way. Worth a try... When will
>> we have code...?
>
> Adding a copy of vcl to binfilter won't help as you can't have two
> instances of the vcl Application class (including its pseudo-static
> data).
...whereby the binfilter version would be in the binfilter namespace.
Maybe there is a creative way to have a vcl Application class in the
binfilter namespace.
The only way to solve the problem would be reimplementing the vcl
> based part of binfilter so that is only uses a stable API to vcl code.
I had more in mind to implement the still needed parts. Should be
(hopefully) not too much, painting and other stuff is completely
removed, thus the static data should be not needed in most cases or
being replacable. The second depends on a try I guess. We will never be
able to guess all needed stuff by discussing.
> This could be achieved by using UNO APIs where possible and defining the
> remaining used C++ APIs as "stable". "stable API" means: defining a time
> period where they are guaranteed to remain compatible so that binfilter
> does not need an update even if the office version is changed.
Too dangerous, I would not try that.
> Of course
> that would be quite some work to do as binfilter surely uses a lot of
> vcl code here and there.
Hopefully not :-)
> Regards,
> Mathias
>
Regards,
Armin
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 05.08.2011 17:21, Armin Le Grand wrote:
> Hi Mathias,
>
> Am 05.08.2011 16:25, schrieb Mathias Bauer:
>> On 05.08.2011 13:33, Armin Le Grand wrote:
>>
>>> [1] Do the not too difficult step of making binfilter independent from
>>> the rest by statically linking, keep it on the current version. Use the
>>> resulting binary module for future versions.
>>
>> As long as binfilter runs in the same process, you can't link it
>> statically against vcl.
>
> Yes, right. Thanks for the hint. Thus, the remaining missing stuff has
> to be stripped and added in the binfilter way. Worth a try... When will
> we have code...?
Adding a copy of vcl to binfilter won't help as you can't have two
instances of the vcl Application class (including its pseudo-static
data). The only way to solve the problem would be reimplementing the vcl
based part of binfilter so that is only uses a stable API to vcl code.
This could be achieved by using UNO APIs where possible and defining the
remaining used C++ APIs as "stable". "stable API" means: defining a time
period where they are guaranteed to remain compatible so that binfilter
does not need an update even if the office version is changed. Of course
that would be quite some work to do as binfilter surely uses a lot of
vcl code here and there.
Regards,
Mathias
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Hi Mathias,
Am 05.08.2011 16:25, schrieb Mathias Bauer:
> On 05.08.2011 13:33, Armin Le Grand wrote:
>
>> [1] Do the not too difficult step of making binfilter independent from
>> the rest by statically linking, keep it on the current version. Use the
>> resulting binary module for future versions.
>
> As long as binfilter runs in the same process, you can't link it
> statically against vcl.
Yes, right. Thanks for the hint. Thus, the remaining missing stuff has
to be stripped and added in the binfilter way. Worth a try... When will
we have code...?
> Regards,
> Mathias
Regards,
Armin
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 05.08.2011 13:33, Armin Le Grand wrote:
> [1] Do the not too difficult step of making binfilter independent from
> the rest by statically linking, keep it on the current version. Use the
> resulting binary module for future versions.
As long as binfilter runs in the same process, you can't link it
statically against vcl.
Regards,
Mathias
Re: binfilter (was RE: OOO340 to svn)
Posted by Armin Le Grand <Ar...@me.com>.
Hi *,
Binfilter can pretty simply be linked statically against the remaining
dependencies (tools and below) and just stay there as a binary module.
It already is a UNO API based module, so having binfilter or not is just
a matter of copying the binaries or not during installation, plus maybe
some finetuning.
My initial suggestion was anyways to not add it as a module, but keep it
static on the version it was added in the past; being indirectly changed
by changing the below modules for other purposes is theoretically even
dangerous and may introduce errors.
Seen from today I see no reason at all to keep it; there are about 20
versions of OOo/other derivates out there which support it and thus
support converting documents. Everyone who still has old docs (few after
7-8 years I guess) is able to get a version before removal, install it
and convert those docs.
As discussed above, there are two possibilities (well, three, if we keep
it as it is):
[1] Do the not too difficult step of making binfilter independent from
the rest by statically linking, keep it on the current version. Use the
resulting binary module for future versions.
[2] Completely remove it and refer any complaints from people which were
not able to move to the new file formtats in the last 7-8 years to the
countless versions which are capable to do the conversion
Thus I clearly suggest to do [2] now, enough ressources (memory,
bandwidth, built time, ...) spent on it. Let's use the chance to cut
some old burdens.
BTW: Fo the interested I already mentioned some facts about it's history
here [news://news.gmane.org:119/iufajg$339$1@dough.gmane.org]
Am 03.08.2011 21:17, schrieb Mathias Bauer:
> On 03.08.2011 20:25, Dennis E. Hamilton wrote:
>
>> What I managed to glean from the LibreOffice discussion lists is that
>> binfilter will be separately installable but probably not taken to
>> end-of-life. (As platforms change, it may be necessary to make new
>> builds of it.)
>
> Binfilter already is installable separately - on Windows it's an option
> in the setup that you can disable (and AFAIK it is disabled by default).
> What you probably mean is that they are discussing to make binfilter a
> component that is compatible cross versions and so does not need to be
> installed each time when a new version of the office program is installed.
>
> As this currently fails due to some dependencies between binfilter and
> "the rest of the office" that are not stable enough and might change in
> every release, this ends up in the discussion you mentioned:
>
>> There is also discussion about moving some annoying dependencies into
>> the binfilter (and other converter) branches in some case, so they
>> don't have to be maintained in sync with the main distro.
>
> That's nothing new and this has happened in the past already in several
> cases. I did that by myself on several occasions. But this approach is
> doomed to fail in at least two cases: GraphicObjects and vcl. At least
> it would require to refactor large parts of the binfilter code to be
> able to remove these dependencies. There are much more better places
> where time could be invested better. [Remark: IMHO the GraphicObject
> problem should be solvable with moderate effort, I doubt that this is
> the case for vcl.]
>
> But maybe this is just a problem because people want to see a problem in it.
>
> Though in theory binfilter creates some maintenance effort due to its
> remaining dependencies on other code, I can't remember a lot of
> necessary work on binfilter caused by these dependencies in the last
> years. In the past we already went the "remove annoying dependencies"
> road for binfilter: each time when a developer made huge changes in a
> module that would require larger code adjustments in binfilter, the
> module that was going to be changed was copied before the change and the
> unmodified copy was moved into binfilter (and hopefully ;-) stripped
> from all code not used in binfilter later). As I wrote, this doesn't
> work for the GraphicObject and vcl, but we already used it for most of
> the bigger modules with a lot of code changes, so I don't expect a lot
> of room for improvement here.
>
> It should be mentioned that this approach only optimized the work from a
> maintencance cost POV, but it made things worse in other areas:
> binfilter becomes bigger each time when a copied module was added,
> increasing both build time and size of the installation set. And even
> the optimization for maintenance cost is incomplete as the resulting
> code duplication will require duplicated work in the future at least in
> case security leaks are found (been there, done that ...).
>
>> There is also a thrust to make converters more cleanly-separated and
>> having the plugin APIs work successfully for them. Again, this is
>> the gist of it. It doesn't seem too far from ideas that have been
>> floated around here, though.
>
> I'm afraid that talking about stuff like this without actually knowing
> the code will at best create confusion. So all I will say about that
> here is:
>
> We don't have converters, we have filters. And some of them are cleanly
> separated already, some aren't. As long as the latter aren't going to be
> reimplemented anyway, there wouldn't be much sense in investing time
> into improving their modularity.
>
> Is binfilter the next "bike shed" we are targetting?
>
> Regards,
> Mathias
>
--
ALG
Re: binfilter (was RE: OOO340 to svn)
Posted by Mathias Bauer <Ma...@gmx.net>.
On 03.08.2011 20:25, Dennis E. Hamilton wrote:
> What I managed to glean from the LibreOffice discussion lists is that
> binfilter will be separately installable but probably not taken to
> end-of-life. (As platforms change, it may be necessary to make new
> builds of it.)
Binfilter already is installable separately - on Windows it's an option
in the setup that you can disable (and AFAIK it is disabled by default).
What you probably mean is that they are discussing to make binfilter a
component that is compatible cross versions and so does not need to be
installed each time when a new version of the office program is installed.
As this currently fails due to some dependencies between binfilter and
"the rest of the office" that are not stable enough and might change in
every release, this ends up in the discussion you mentioned:
> There is also discussion about moving some annoying dependencies into
> the binfilter (and other converter) branches in some case, so they
> don't have to be maintained in sync with the main distro.
That's nothing new and this has happened in the past already in several
cases. I did that by myself on several occasions. But this approach is
doomed to fail in at least two cases: GraphicObjects and vcl. At least
it would require to refactor large parts of the binfilter code to be
able to remove these dependencies. There are much more better places
where time could be invested better. [Remark: IMHO the GraphicObject
problem should be solvable with moderate effort, I doubt that this is
the case for vcl.]
But maybe this is just a problem because people want to see a problem in it.
Though in theory binfilter creates some maintenance effort due to its
remaining dependencies on other code, I can't remember a lot of
necessary work on binfilter caused by these dependencies in the last
years. In the past we already went the "remove annoying dependencies"
road for binfilter: each time when a developer made huge changes in a
module that would require larger code adjustments in binfilter, the
module that was going to be changed was copied before the change and the
unmodified copy was moved into binfilter (and hopefully ;-) stripped
from all code not used in binfilter later). As I wrote, this doesn't
work for the GraphicObject and vcl, but we already used it for most of
the bigger modules with a lot of code changes, so I don't expect a lot
of room for improvement here.
It should be mentioned that this approach only optimized the work from a
maintencance cost POV, but it made things worse in other areas:
binfilter becomes bigger each time when a copied module was added,
increasing both build time and size of the installation set. And even
the optimization for maintenance cost is incomplete as the resulting
code duplication will require duplicated work in the future at least in
case security leaks are found (been there, done that ...).
> There is also a thrust to make converters more cleanly-separated and
> having the plugin APIs work successfully for them. Again, this is
> the gist of it. It doesn't seem too far from ideas that have been
> floated around here, though.
I'm afraid that talking about stuff like this without actually knowing
the code will at best create confusion. So all I will say about that
here is:
We don't have converters, we have filters. And some of them are cleanly
separated already, some aren't. As long as the latter aren't going to be
reimplemented anyway, there wouldn't be much sense in investing time
into improving their modularity.
Is binfilter the next "bike shed" we are targetting?
Regards,
Mathias
RE: binfilter (was RE: OOO340 to svn)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
What I managed to glean from the LibreOffice discussion lists is that binfilter will be separately installable but probably not taken to end-of-life. (As platforms change, it may be necessary to make new builds of it.)
There is also discussion about moving some annoying dependencies into the binfilter (and other converter) branches in some case, so they don't have to be maintained in sync with the main distro.
This means there's potentially redundant maintenance. I am not sure where they went with that, and how far they can go with it. I also have no idea how the trees are being reorganized at LibreOffice.
There is also a thrust to make converters more cleanly-separated and having the plugin APIs work successfully for them. Again, this is the gist of it. It doesn't seem too far from ideas that have been floated around here, though.
I think we should have a mutual interest in coordinating more around this topic, since redundant development and maintenance of converters is a terrible tax on developer attention and resources. There is considerable interoperability impact, although maybe not so much for the very stable, near-ancient ones (although just staying up with RTF seems to be a serious challenge).
- Dennis
-----Original Message-----
From: Malte Timmermann [mailto:malte_timmermann@gmx.com]
Sent: Wednesday, August 03, 2011 10:24
To: ooo-dev@incubator.apache.org
Subject: Re: binfilter (was RE: OOO340 to svn)
Binfilter will be good for many more time consuming discussions. Many
different opinions on if/how to change them, many different opinions on
if/why to keep them.
Assuming that the binfilter source tree doesn't need clean-up because of
IP / license issues, I suggest to simply keep the folder as it is, and
think about further actions later.
I really wouldn't spend resources on this topic now, as there are too
many important things we need to achieve before.
Not sure about the status of binfilter in LibreOffice - but IIRC, once
the Linux distros where shipping Go-OO versions, they didn't include
binfilters, and I can't imagine LibO being different here.
As a side note - OOo 3.3 doesn't install binfilters per default anymore,
and I can't remember anybody complaining/wondering/asking.
In Oracle Open Office, we already had an EOL note for them.
Malte.
On 03.08.2011 18:19, eric b wrote:
>
> Le 3 août 11 à 17:49, Dennis E. Hamilton a écrit :
>
>> I believe LibreOffice is already taking action on binfilter, and it
>> would be useful to see if we can match their approach.
>>
>> Also, I think there was (again on LibreOffice) a technical discussion
>> on simplifying the dependencies.
>
>
> I did a lot on simplifying the dependencies with OOo4Kids and OOoLight,
> but before I need to know what you need to simplify.
>
> About binfilter, there are several issues :
>
> 1) the binfilter directory contains duplicated headers. I had a private
> discussion about that with Jens Heiner Linkenau, aka ause, and I can
> retrieve everything about the exact reasons why.
>
> 2) for compatibility reason, and as good compromise OpenOffice.org
> should to continue to provide a way to "open" old format files
> (staroffice 5.x for instance), and to propose to save them in a more
> recent.
>
> 3) build binfilter means there are a lot of warnings, and warnings are
> error. I worked a lot on remove warnings on binfilter, and I can help on
> this side, if ever (or students can help for sure).
>
>
> I got other ideas, about simplifying the build, but I'll keep them for a
> best moment (too early now)
>
>
>> This was initially by having redundancy, with the idea that a better
>> refactoring would come later.
>
>
> I must have missed some mails. What is the current plan ?
>
>
> Regards,
> Eric Bachard
>
>
Re: binfilter (was RE: OOO340 to svn)
Posted by Malte Timmermann <ma...@gmx.com>.
Binfilter will be good for many more time consuming discussions. Many
different opinions on if/how to change them, many different opinions on
if/why to keep them.
Assuming that the binfilter source tree doesn't need clean-up because of
IP / license issues, I suggest to simply keep the folder as it is, and
think about further actions later.
I really wouldn't spend resources on this topic now, as there are too
many important things we need to achieve before.
Not sure about the status of binfilter in LibreOffice - but IIRC, once
the Linux distros where shipping Go-OO versions, they didn't include
binfilters, and I can't imagine LibO being different here.
As a side note - OOo 3.3 doesn't install binfilters per default anymore,
and I can't remember anybody complaining/wondering/asking.
In Oracle Open Office, we already had an EOL note for them.
Malte.
On 03.08.2011 18:19, eric b wrote:
>
> Le 3 août 11 à 17:49, Dennis E. Hamilton a écrit :
>
>> I believe LibreOffice is already taking action on binfilter, and it
>> would be useful to see if we can match their approach.
>>
>> Also, I think there was (again on LibreOffice) a technical discussion
>> on simplifying the dependencies.
>
>
> I did a lot on simplifying the dependencies with OOo4Kids and OOoLight,
> but before I need to know what you need to simplify.
>
> About binfilter, there are several issues :
>
> 1) the binfilter directory contains duplicated headers. I had a private
> discussion about that with Jens Heiner Linkenau, aka ause, and I can
> retrieve everything about the exact reasons why.
>
> 2) for compatibility reason, and as good compromise OpenOffice.org
> should to continue to provide a way to "open" old format files
> (staroffice 5.x for instance), and to propose to save them in a more
> recent.
>
> 3) build binfilter means there are a lot of warnings, and warnings are
> error. I worked a lot on remove warnings on binfilter, and I can help on
> this side, if ever (or students can help for sure).
>
>
> I got other ideas, about simplifying the build, but I'll keep them for a
> best moment (too early now)
>
>
>> This was initially by having redundancy, with the idea that a better
>> refactoring would come later.
>
>
> I must have missed some mails. What is the current plan ?
>
>
> Regards,
> Eric Bachard
>
>
Re: binfilter (was RE: OOO340 to svn)
Posted by eric b <er...@openoffice.org>.
Le 3 août 11 à 17:49, Dennis E. Hamilton a écrit :
> I believe LibreOffice is already taking action on binfilter, and it
> would be useful to see if we can match their approach.
>
> Also, I think there was (again on LibreOffice) a technical
> discussion on simplifying the dependencies.
I did a lot on simplifying the dependencies with OOo4Kids and
OOoLight, but before I need to know what you need to simplify.
About binfilter, there are several issues :
1) the binfilter directory contains duplicated headers. I had a
private discussion about that with Jens Heiner Linkenau, aka ause,
and I can retrieve everything about the exact reasons why.
2) for compatibility reason, and as good compromise OpenOffice.org
should to continue to provide a way to "open" old format files
(staroffice 5.x for instance), and to propose to save them in a more
recent.
3) build binfilter means there are a lot of warnings, and warnings
are error. I worked a lot on remove warnings on binfilter, and I can
help on this side, if ever (or students can help for sure).
I got other ideas, about simplifying the build, but I'll keep them
for a best moment (too early now)
> This was initially by having redundancy, with the idea that a
> better refactoring would come later.
I must have missed some mails. What is the current plan ?
Regards,
Eric Bachard
--
qɔᴉɹə
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news