Hacker News new | past | comments | ask | show | jobs | submit login

This appears to be a git-like backend for Microsoft Office documents; initially starting with Power Point.

There are web based solutions from wikis, to trackers, and things like Google Docs and eversion allow many people to collaborate on a document at the same time (eversion does it in real time).




We're starting off where we know people really have the problem - with MS office files stacked away on old network drives. In the long run we want to integrate with any file type - Photoshop, CAD etc. Wherever there's currently v1, v2, v3, v5_tommy_edit2 we think there's room for improvement.


How do you plan to manage changes in binary files?


Office docs can be exported to xml. Wherever possible we serialise to a git friendly format, if this isn't possible we'll version the binary itself. But we'd love any tips you have!


So if you diff xml docs, will users be expected to read the raw xml diff output? Or, is there enough documentation on the file formats available so that when you diff two Word docs, for example, that you can create a third doc using Word's "show revisions" feature?


hey derek, Leo here -- I'm CTO at kivo. So, although the PowerPoint COM API is super old and buggy, the OpenXML standard which has been around since Office 2007 is actually pretty advanced. This means that you can realistically diff two versions of a file and extract and analyze the changes. The C# wrapper for this is also good (the hard bit is actually serializing the slide from COM -> OpenXML in memory). We would never expect our users to read the XML!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: