JBrickBuilder connection model


Re: JBrickBuilder connection model
#26
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:

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
Reply
« Next Oldest | Next Newest »



Messages In This Thread
Re: JBrickBuilder connection model - by Ben Supnik - 2015-02-06, 21:28

Forum Jump:


Users browsing this thread: 4 Guest(s)