Re: [Gnu3dkit-dev] Strings and parameter lists

Hi,

Some points :

> The question here is do we want to be able to read, write or read and 
> write RIB files. If we ie. only have to write RIBs then we could ie. 
> provide a special action implementation which generates a RIB from the 
> scene graph.

About RIB, it would be very nice to have read and write RIB, obviously 
the writing is the easiest. I am working on it now, not too fast but I 
am working on it :) I didn't find nothing open source to read rib 
files. I am hesitating to write my own parser or use lex and yacc (well 
flex and bison). In fact this capacity would a big plus for our 3DKit...

> Wrt the drawing API I think that if we can come up with an API 
> covering all of the RM primitives then we cover already a good portion 
> of what we need.

Exactly, if we can parse a rib file then we have a lot of stuff :)

> working on the renderer API I encounter some problem/issues with 
> strinsgs. In RenderMan everything is handled via C strings (tokens), 
> back in the NEXTSTEP days this would have been used directly 'as is'.
> Now since OpenStep the use of NSString is recommended and C strings 
> are more or less banned from the API although this imposes some 
> overhead.

But using stringWithCString to build the c string use optimized 
NSString backend, I believe.

> My problem now is how to map the RenderMan C interface to a proper 
> G3DRenderer Objective-C interface: should we use plain C strings or 
> NSStrings?

We have to be consistent, and not optimize the stuff too early. The 
ObjC API has to use NSString, we will see if this is a issue.

> Moreover RenderMan uses parameter lists in many places which could be 
> handled either via variable argument lists or NSDictionary objects. 
> I'd prefer to use the latter (from an OO perspective), but I'd like to 
> hear your opinion on that as well before I go on here.

I have the same opinion as you, variable list of arguments is hard to 
debug.

But NSDictionary is costly :(

I vote for the NSDictionary for now.

> So the main question here is probably whether we want to design a pure 
> Objective-C API or mix it with a C interface. Again, I'd choose the 
> Objective-C approach, but...

I think that we have to make ObjC first, because if speed become a real 
issue I think that it will be better to give a complete equivalent C 
interface, a little bit as CoreFoundation/Foundation


Best regards

	Gerard