[LSC] Long filenames in the official library

[Chris Dee]

Good point on the casing. The official library is always distributed with
lower case filenames, but since it is primarily Windows based, internal file
references (in type 1 lines) are often written in mixed case. 

 

This could be policed (and maybe even fixed as part of the CA compliant
complete update), but there is a historical reason for some stud.dat
references being STUD.dat. I am not sure it is well documented, because I
couldn't find it in the specifications. IIRC the point was to prevent
renderers from substituting with a low-res or "line" stud. It may only have
been implemented in LEDIT. In most case this is where a stud has been used
in an abnormal location, and probably should not have been used.

 

Chris   

 

  _____  

From: lsc-bounces at ldraw.org [mailto:lsc-bounces at ldraw.org] On Behalf Of
Travis Cobbs
Sent: 15 May 2007 23:47
To: LDraw Standards Committee
Subject: Re: [LSC] Long filenames in the official library

 

OK, I'm going to put the proposal here for comments, and then after things
have settled, I'll call a vote.

Begin Proposal

Update "LDraw.org File Format Version 1.0.0" (draft), found here:
http://www.ldraw.org/Article218.html

In the Line Type 1 section, change the <file> paragraph to read as follows:

<file> is the filename of the file referenced. Files can be located
LDRAW\PARTS, LDRAW\P, LDRAW\MODELS, the current file's directory, or a path
may be specified. There is no limit on how far these files can be nested.
<file> should not contain any spaces. 



Create a new specification document, to be filed in the "LDraw.org Official
Library Standards" section of the ldraw.org specifications page (
http://www.ldraw.org/Article292.html).  The title of the document will be
"Special Requirements for Official Library Files", and will contain the
following text: 

The official library header (found at http://www.ldraw.org/Article398.html)
must appear at the top of the file. 

The <file> portion of Type 1 lines will be made up of an optional path,
followed by a filename.  The filename may not be any more than 25 characters
long (including the .dat extension) and may only contain the following
characters: a-z, A-Z, 0-9, _, and -, followed by ".dat".  If there is a path
preceding the filename, it must be one of the following:
s\
48\

End Proposal


I included the change to the 1.0 draft because even though it's still in
draft, it doesn't seem right to have it more restrictive than what is
allowed in official library files.  Since it is still in draft, we don't
necessarily have to agree that what I put is good for the long haul, just
that making the above change to the draft document is acceptable. 

As a future action, we should really consider officially ratifying the 1.0.0
file format spec.  It was created in September of 2003; I think it's about
time it became official.

I used 25 characters as a maximum filename length arbitrarily.  I'm
certainly open to increasing it, but I do feel that we should specify some
maximum, and I don't think it should be less than 25. 

It occurs to me that we should probably disallow upper case letters in
official files.  I included them in the above proposal, but can anyone
provide a reason why mixed case official library filenames would be
advantageous?  On that note, forcing them to be all lower case in the
library files and arranging to that the official library distribution uses
all lower case allows easier (and faster) implementations on operating
systems with case-sensitive filenames.  I know that LDView in Linux takes
MUCH longer to load models if the part library is stored in all upper case
letters on a case-sensitive file system, since LDView tries all lower case
first, then does a glob search. 

The new document should probably have more meat.  I'm pretty sure that there
are other restrictions placed on library files.  It would be nice to have
those all documented in one place.  However, for the purposes of this
proposal, what's there should be OK. 


--Travis

On 5/13/07, Chris Dee <chris_w_dee at hotmail.com> wrote:

I also accept, although I will need to think carefully about the impact on
the official part naming standards.

On the character set - I would veto the use of '#', due to the problems of
needing to deal with that within a URL. That's why we renamed the box3#8p 
primitive. [A-Z],[a-z],[0-9], _ and - are OK with me.

Chris


> -----Original Message-----

> From: lsc-bounces at ldraw.org [mailto: lsc-bounces at ldraw.org

<mailto:lsc-bounces at ldraw.org> ] On Behalf Of

> Tore Eriksson

> Sent: 13 May 2007 22:11

> To: LDraw Standards Committee

> Subject: Re: [LSC] Long filenames in the official library

>

> I think it will cause some problems, but not insurmountable. As I, the 

> most Conservative and stubborn no-to-all-changes voter, now approve to

> this change, I guess all resistance has been overcome.

>

> /Tore

>

>

>

> ----- Original Message ----- 

> From: "Lars C. Hassing" <lars at hassings.dk>

> To: "LDraw Standards Committee" <lsc at ldraw.org>

> Sent: Thursday, May 10, 2007 12:41 AM 

> Subject: Re: [LSC] Long filenames in the official library

>

>

> > I'm fine with long filenames.

> > /Lars

> >

> > Travis Cobbs skrev:

> > > I'm going to try to revive this discussion.  At this point, I'm 

> > > personally in favor of allowing long filenames, as long as we strictly

> > > control the character set that's allowed in them (probably

> > > alphanumeric, plus underscore and dash, and maybe #). 

> > >

> > > There's no sense spending the time coming up with a new policy if long

> > > filenames are going to be voted down completely, so I'd like everyone

> > > to vote yes or no on whether you're open to allowing long filenames. 

> > > My vote is yes.  Note that this vote just determines if we continue on

> > > to draft an official spec for allowed filenames.  Until (if) we agree

> > > on that, nothing happens. 

> > >

> > > --Travis

> > >

> > > On 4/4/07, *ldraw at holly-wood.it <mailto:ldraw at holly-wood.it

<mailto:ldraw at holly-wood.it> >*

> > > <ldraw at holly-wood.it <mailto:ldraw at holly-wood.it> > wrote:

> > >

> > >     guys, 

> > >

> > >     I just wanna make sure you bring this to a happy or sad

> > >     ending.

> > >

> > >     w.

> > >

> > >

> > > 

> > >

> > >     ----- Original Message -----

> > >     Da : "Travis Cobbs" <tcobbs at gmail.com <mailto: tcobbs at gmail.com

<mailto:tcobbs at gmail.com> >>

> > >     A : "LDraw Standards Committee" < lsc at ldraw.org

> > >     <mailto:lsc at ldraw.org >>

> > >     Oggetto : Re: [LSC] Long filenames in the official library

> > >     Data : Wed, 28 Mar 2007 16:59:54 -0700

> > >

> > >     > Kevin clarified that LPub/LSynth should only have problems 

> > >     > with long filenames that contain spaces.  We definitely

> > >     > don't want to allow that in the library, so at this point

> > >     > I'd say that perhaps the best bet would be to somehow get 

> > >     > an idea of which programs would have problems with long

> > >     > filenames.

> > >     >

> > >     > --Travis

> > >     >

> > >     > On 3/28/07, Travis Cobbs < tcobbs at gmail.com

> > >     <mailto:tcobbs at gmail.com>> wrote:

> > >     > >

> > >     > > Please read this thread on LUGNET if you have not 

> > >     > already done so: >

> > >     > > http://news.lugnet.com/cad/?n=14492

> > >     > >

> > >     > > I think we should discuss whether or not to allow long 

> > >     > > filenames in files in the official library.  At this

> > >     > > point in time, I'm personally leaning toward maintaining

> > >     > > the 8.3 limitation, based mostly on Kevin's comment that 

> > >     > supporting long filenames would require updates to

> > >     > > LPub/LSynth.  Not so much that he has to update them,

> > >     > > but that his need to update them could very well 

> > >     > indicate the same need in many other LDraw-compatible

> > >     > > programs. Frankly, I'm surprised that they would need to

> > >     > be updated. >

> > >     > > Unfortunately, I think that empirical testing of

> > >     > > existing programs is the only way we're going to be able

> > >     > > to have a good idea about current levels of support.  I 

> > >     > for one don't relish doing those tests.  We can ask for

> > >     > > program authors to chime in with a yea or nay on LUGNET,

> > >     > > but I'll be surprised if get get a representative 

> > >     > response. >

> > >     > > --Travis

> > >     > >

> > >     > >

> > >     >

> > >     >

> > >     > _______________________________________________ 

> > >     > LSC mailing list

> > >     > LSC at ldraw.org <mailto:LSC at ldraw.org>

> > >     > http://five.pairlist.net/mailman/listinfo/lsc

> > >     <http://five.pairlist.net/mailman/listinfo/lsc>

> > >     >

> > >     _______________________________________________ 

> > >     LSC mailing list

> > >     LSC at ldraw.org <mailto:LSC at ldraw.org>

> > >     http://five.pairlist.net/mailman/listinfo/lsc

> > >     <http://five.pairlist.net/mailman/listinfo/lsc>

> > >

> > > 

> > > ----------------------------------------------------------------------

> --

> > >

> > > _______________________________________________

> > > LSC mailing list

> > > LSC at ldraw.org

> > > http://five.pairlist.net/mailman/listinfo/lsc

> > >

> > _______________________________________________ 

> > LSC mailing list

> > LSC at ldraw.org

> > http://five.pairlist.net/mailman/listinfo/lsc

> _______________________________________________ 

> LSC mailing list

> LSC at ldraw.org

> http://five.pairlist.net/mailman/listinfo/lsc


_______________________________________________ 
LSC mailing list
LSC at ldraw.org
http://five.pairlist.net/mailman/listinfo/lsc

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://five.pairlist.net/pipermail/lsc/attachments/20070516/f4691268/attachment-0001.html>