Re: [Planner Dev] Suggestion regarding file extensions: suggesting compressed XML files.

["lincoln phipps openmutual net" <lincoln phipps openmutual net>]

Steve deRosier wrote:

> Just one comment...
>
> Zipped up (compresed, gzip, tar, whatever) versions of nice text-based 
> files drive me nuts.  Text-based files are really nice because they can 
> be versioned with tools such as CVS.  Binary files (and zipping up a 
> bunch of text based files is still a binary file) can't be versioned 
> with CVS (well, they can, kinda... if you don't really care about 
> looking at the difference between versions, and you remember to "tell" 
> CVS it is a binary file you're checking in).

If people want to use CVS to version project plans then they can still
use the current text XML format.

What I'm thinking of is how we could make Planner more functional for
a project i.e. having project logos as jpeg/png files, attaching custom css
for HTML pretty-printing, bundling contract documents.

It was also the idea that a ZIP format this was the sort of format that
would be nice to email around to people or push to web based portals
(A 100 task/5 resource project with no task notes or calendars is around
40kbytes plain or 4300 bytes compressed).

> OpenOffice drives me nuts for this exact reason.  Everyone always says 
> how great it is that OO.o has human readable XML files as their format. 
>  Sorry, but no, the've got a binary file.  Granted by running it through 
> unzip you get XML files (I just unziped one of my documents...7 files 
> and 1 directory, honestly how is that more readable than a single rtf 
> file anyway?  Granted rtf is a miserable format that no one should ever 
> have to read, but at least it is one single text file.  And the XML 
> files that OO.o creates aren't really any more readable anyway.) but 
> you've got to do that extra step and you still can't really version the 
> file as a whole.

The trouble here is that its not like source code - a project plan
has an internal integrity that makes it not very nice to try and
play with this by hand. Same with OOO files. What the stylist has
applied and where needs to be kept in sync with the text payload.
If they get out of step then the document is broken. Its a bit like
versioning a set of database tables - not easy. Best to have the
versioning within the application.

I've had to look at Microsoft Word/RTF files in anger using ASCII
to extract the contents of a corrupt document manually but I've
never had to look at OOO files in anger.

XML can be made to be just as unreadable as a binary - the essential
feature is a published format (without Patents locking it down).
From a Perl programs point of view nothing is unreadable, binary
or XML. The question is: is it documented and patent free ?
With RTF/Word/Office2003XML - not always true but with OOO always
true.

> Anyway, sorry about the little rant, but I think it's importaint to 
> think about this angle before deciding on the binary file format path.

Yup - but I was thinking of BOTH methods, a compressed file format
(which is just the same file zipped up with any extra added stuff)
and the current .planner (well .mrproject) file format which is
what the parser would have look at anyway once it unzipped the
file.

CVS has always had issues with binaries thus the regular text ASCII
should always be available. Its where people have other document
management systems e.g. Subversion ;) or commercial document
management systems like Notes, or portal based systems (like any
of the *nukes or things like Tutos) where you upload new copies
of the file, that a single zipped file is a good thing.

Rgds,
Lincoln.
> Just my 2 cents.
>
> - Steve
>
> lincoln phipps openmutual net wrote:
>
> > Been thinking about this and wondered if it may be nice to
> > do this in the way similar to other applications,
> >
> > a) Create a compressed file format e.g. same as what the OpenOffice
> > XML files do. e.g. call this .pxz  - Meaning Planner XML Compressed.
> >
> > b) Inside that .pxz file use regular XML files like myfile.planner
> > (or myfile.mrproject for legacy support)
> >
> > c) Have Planner able to either open the .pxz or .planner (or *.mrproject
> > for legacy support).
> >
> > The advantage of a compressed file format is that its nicer to mail
> > and store and it allows some simple payload protection in checksums.
> >
> > The file can also be used to carry non-XML data like images or stuff
> > which could be used in formatted outputs e.g. HTML pages could have
> > logos which are actually carried as part of the pxz file.
> >
> > Thoughts ?.
> > Lincoln.
> > _______________________________________________
> > Planner-dev mailing list
> > Planner-dev lists imendio com
> > http://lists.imendio.com/mailman/listinfo/planner-dev
>
> _______________________________________________
> Planner-dev mailing list
> Planner-dev lists imendio com
> http://lists.imendio.com/mailman/listinfo/planner-dev