In designing interfaces for building planes, writing plugins, etc. one of the main design questions that keeps coming up is: to copy or to reference? Should authors simply refer to an art asset, piece of data, or code in order to utilize it, or should the author copy a snapshot into the custom add-on. There isn’t one right answer. Here are the main considerations.
Performance and Efficiency
One of the obvious considerations is efficiency: in some cases we might be able to provide better performance when an art asset is referred from a common source.
For example, in some cases X-Plane will consolidate VRAM use based on actual files, so a library object is loaded once no matter how many packages use it, but is loaded many times if a package copies it.
(In other cases X-Plane will actually merge multiple copies of a resource – referencing is only a win in some cases.)
An indirect consideration: if an art asset is provided by Laminar Research and is used by reference, then a new update can provide a new, better optimized art asset – see below.
Dependencies and Contracts
When someone uses an art asset, algorithm, etc. by reference, it creates an implicit contract by the provider of the asset by reference to not change the properties of the asset. By comparison, when the asset is copied, the contract is only to support the format that the asset is encoded in.
This is the main reason why I am often against providing new assets by reference, whether it is a new dataref, texture, etc. Often I will simply send a user a snippet of code, rather than making X-Plane’s version available via a dataref. The idea is that copying does not create a new interface (and thus a new “contract”) between X-Plane and the add-on.
Copyright and Legal Issues
For historical reasons, the US legal system describes the privileges of intellectual property owners by regulating the act of copying. (To say that this is a bit quaint in the digital age doesn’t even scratch the surface, but that’s a rant for another post.) The result of this particular regulation of copying (but not of referencing) is that the decision to provide an asset by copy vs. reference has legal implications. If the author does not want to go through licensing, referencing may be the only option.
I read some astute observations here, but I'm foggy on the context or concerns that would stimulate this particular entry. Clearly, the more a particular X-Plane operating data asset can be referenced, the more efficiency that can be realized in whatever function that requires the asset. Copying/Referencing within code….legal issues…certainly one of the pitfalls of providing an application that has as much user based design flexibility. But I'm curious….what truly stimulated this bit of blogging, Ben?
Hi Steve,
This issue is so common that there are several things in the last 3 days of development that hit this.
– Autopilot … do we provide access to part of the AP or do I just email plugin authors the snippet of code they want access to? (My answer: copy…avoid dependencies on the internals of the AP.)
– Named lights … do we provide users a way to create their own named lights, or are light billboards accessed by reference e.g. "the name"? (My answer: reference…by keeping all light "data" in the sim we are in a position to substantially improve our light billboard art assets and shaders.)
– Airport terminal elements…this was discussed in France. (My answer: reference…LR has a policy of trying to retain very restricted IP licensing of art assets, but obviously we want people to be able to use them – the above thought on future optimization applies too.)
– New instruments…do we make more new default instruments or just provide art assets and let people use them? (My answer: copy…goes against IP policy for art assets above, so I may get push-back, but I tend to think that "owning" 600 instruments is proving to be annoying for LR…we'd be better off giving people some templates, maybe even on the web, and keeping the panel code simple.)
And that's just what I can think of right now…