I was writing a recursive node copy function using the 2008 wiretap SDK, and noticed on our new LINUX Flame 2008 boxes that where DESKTOP nodes would normally exist, there are actually REEL nodes, with mutliple REEL nodes nested underneath. This seems to be a result of Flame 2008 saving it this way (with a REEL node instead of a DESKOP node)
My question is, is this a bug in Flame 2008 or a problem with the Wiretap SDK? I receive an exception when trying to create a REEL under another REEL, which I admit should be wrong. But SOMEHOW the Flame GUI is performing this operation.
It has unfortunately always been the case that the Desktop is not exposed as a library. There are historical/architectural reasons for this. Users are required ot save clips to libraries in order for them to be seen through Wiretap.
WRT reels being children of reels, Wiretap intentionally prevents this. Not all functionality deployed in IFFFS is actually visible through Wiretap ... but we do take requests.
I did happen to check the documentation and notice that this restriction is not documented. I'll log a bug to fix it.
Thanks for the reply, Dan.
I just want to make sure I understand what you have written. Are you referring to the active Desktop that is being used, not being exposed to WT?
I am referring to saved desktops that aren't in use. I could have sworn that on our old SGI systems just before we upgraded, I would use the print_tree tool and see structures like: PROJECT -> LIBRARY ->DESKTOP -> REEL -> CLIP. But now with the new LINUX Flame 2008 boxes, I only see PROJECT -> LIBRARY -> REEL -> REEL -> CLIP (if the use had saved out his desktop to his library)
I'm only now seeing REEL nodes in place of DESKTOP nodes, with more REEL nodes nested underneath, which I thought wasn't possible.