Hi Chris,
First, I second everything Roalnd said. :-)
Second, since we don't actually have a clear definition of what the connectivity data contains, this discussion may be premature.
With that in mind:
That seems like a slightly higher bar than other aspects of the library. For example, we don't put meta data on a part in a separate file because changing the part geometry is unlikely to change the part name or category.
My argument is that the connectivity is a -kind of- part geometry. In this case I'm definitely only arguing for including -connection location data- in the parts, and I'm not entirely sure what other kinds of data we will even ahve.
I think this is a strong argument -in favor- of connectivity in the part. If connectivity was in a single consolidated file, how would we manage multiple authors editing connectivity data on separate parts. That's not an impossible problem (in fact, it's just source control) but we already have -existing- infrastructure based on one part one file that works well.
cheers
Ben
First, I second everything Roalnd said. :-)
Second, since we don't actually have a clear definition of what the connectivity data contains, this discussion may be premature.
With that in mind:
Chris Dee Wrote:I think the main question to ask to decide whether supplementary information (e.g. connectivity metadata) is stored within the part file is 'How often would a correction to the part geometry affect the connectivity metadata?'. If 'hardly ever', then I favour a separate file structure for connectivity info.
That seems like a slightly higher bar than other aspects of the library. For example, we don't put meta data on a part in a separate file because changing the part geometry is unlikely to change the part name or category.
My argument is that the connectivity is a -kind of- part geometry. In this case I'm definitely only arguing for including -connection location data- in the parts, and I'm not entirely sure what other kinds of data we will even ahve.
Quote:I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best.
I think this is a strong argument -in favor- of connectivity in the part. If connectivity was in a single consolidated file, how would we manage multiple authors editing connectivity data on separate parts. That's not an impossible problem (in fact, it's just source control) but we already have -existing- infrastructure based on one part one file that works well.
cheers
Ben