Hey Guys,
As our team grows, the binary nature of .gorm files is becoming untenable.
Because Git cannot merge binary files, concurrent changes result in merge
conflicts where "the last person to merge wins."
While looking for alternatives, I evaluated standard Apple formats but
found significant limitations:

   - XML NIBs: These are referential rather than compositional. Objects are
   serialized into a flat list with positional indexes, making them just as
   difficult to merge as binary files.
   - XIBs: While compositional, Apple controls this format. It changes at
   their whim and is tightly coupled with their specific Cocoa nuances—nuances
   I have spent significant effort reverse-engineering.

While we can easily read these formats, writing to them will always be
imperfect. Therefore, I propose we design a custom, project-controlled
serialization format that meets three criteria:

   1. Compositional Structure: Nested objects should reflect the actual UI
   hierarchy (e.g., nesting an NSView inside an NSWindow tag).
   2. Human-Readable & Editable: This will allow clean version control and
   manual merging.
   3. Project-Controlled: We dictate the schema, protecting us from
   external breaking changes.

*Note: The underlying data format doesn't have to be XML; we can decide
between JSON, Plists, or XML later.*
Implementation Strategy:
To support this, we will need to implement custom versions of initWithCoder:
and encodeWithCoder:. I suggest extending the existing archiver methods to
include a check like allowsXormCoding (working title), similar to
allowsKeyedCoding.
I would love to hear your thoughts on this approach.
Yours, GC

On Tue, Jul 21, 2026 at 12:18 PM R Frith-Macdonald <
[email protected]> wrote:

> Using -[NSDictionary descriptionWithLocale:indent:] I think we can
> already output a gorm file as a text property list with no indentation
> (and it sorts dictionary content by key).
>
> I suspect that format would be highly suitable for diff:
>
> Using no indent means that adding enclosing containers doesn't change
> the lines representing the content of those containers.
>
> Having dictionaries sorted by key means that fields are present in a
> consistent order.
>
> On 21/07/2026 16:41, Riccardo Mottola wrote:
> > David Wetzel via Discussion list for the GNUstep programming
> > environment wrote:
> >> I feel like XML is a format from the past. Why not use a JSON based one?
> >
> > I would use neither, I would just use plists, our native format.
> > Actually, probably both plist as XML-encoded plists would work.
> >
> > JSON is just a bad plist :) and has absolutely no type encoding.
> >
> > Riccardo
> >
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.openhub.net/languages/objective_c
  • P... [email protected]
    • ... David Wetzel via Discussion list for the GNUstep programming environment
      • ... Daniel Santos
      • ... Riccardo Mottola
        • ... R Frith-Macdonald
          • ... Gregory Casamento
            • ... R Frith-Macdonald
              • ... Gregory Casamento
            • ... Katalin Rebhan
        • ... David Wetzel via Discussion list for the GNUstep programming environment
    • ... H. Nikolaus Schaller
    • ... Graham Lee
    • ... Riccardo Mottola

Reply via email to