XMPFile bug

[_xbytor_]

Here's a nasty little bug.

var f = new File(Folder.desktop + '/test.psd');

var xf = new XMPFile(f.absoluteURI,
XMPConst.UNKNOWN,
XMPConst.OPEN_FOR_UPDATE);

This fails with a 'OpenFile returned false' message.

The XMPFile constructor does not take a File object as a first arg. Why? What
reason would it not take a proper File object like the rest of the JS APIs do?

And, apparently, code beneath the XMPFile constructor doesn't understand what
'~' means.

And there is no File/Folder API for determining what '~' is or completing
resolving the path. The absoluteURI property will _always_ substitute '~' for
the home directory if it's possible. So, it's not really absolute. This could be
classified as a bug, too.

The result is that I have to now manually check for a "~/" at the beginning of
every string that I pass to the XMPFile constructor and use $.getenv('HOME') to
determine what '~' is.

Or am I doing something wrong?

This fails identically in Bridge and PS CS4.

-X

[_xbytor_]

xbytor@adobeforums.com wrote:
> Here's a nasty little bug..

Need more sleep :)

File.fsName will resolve the "~' correctly. So it's a little less extra work
than I initially thought.

-X

[dfranzen_camera_raw]

You pretty much always want to use File.fsName when you have to pass a file-system path to another API. The Thumbnail constructor is another good example where it's a good idea to pass File.fsName instead of paths you construct some other way. I also use File.fsName when I want to pass a file path to native code or out to a command-line utility using app.system().

-David

[_xbytor_]

David_Franzen@adobeforums.com wrote:
> You pretty much always want to use File.fsName when you have to pass a file-system path to another API.

I disagree. You shouldn't be required to specify a String (whose format, by the
way, is not clearly specified in the docs) when there is a very well defined and
commonly used object (File, in this case).


> The Thumbnail constructor is another good example where it's a good idea to pass File.fsName instead of paths you construct some other way.

The Thumbnail constructor is a poor counterargument. It takes either one of
these fsName-style strings _or_ a File object. My point is that XMPFile should
do the same. Nearly all of the APIs that I've written for PS and Bridge will
take a File object or path string (whatever format) that I internally convert to
a File object. And I can't recall any constructors in PS or Bridge that only
take a fsName string (though there are many parts of Bridge that I'm not
familiar with). And there are other examples in XMPScript (like the constructor
for XMPMeta) where more than one class of object is allowed as an argument.


> I also use File.fsName when I want to pass a file path to native code or out to a command-line utility using app.system().

As do I. Sort of. I typically have to do something like decodeURI(file.fsName)
to get the path correctly formatted and add "s around it when constructing
scripts for File.exec. (BTW, can you talk to the Ps guys about getting us a
app.system() call? 🙂 I've had a hacked version that I wrote years ago, but it's
problematic on the Mac for a number of reasons.)

But we are not dealing with a low-level system API case here. We are
constructing an object that is supposed to abstract out stuff like that.


I do realize that adding support for File adds a dependency to a class defined
outside of the XMPScript and JS language APIs, but I would think that since File
and Folder are kind of core to ESTK-based apps (like Bridge and Ps) this kinds
of dependency shouldn't really be too much of an issue.

-X

[dfranzen_camera_raw]

Hi X,

You have a good point about the XMPScript API not using the File object. I've logged a feature request bug about this with the XMP team.

You can also raise this issue on the XMP SDK forum: http://www.adobeforums.com/cgi-bin/webx?14@@.ef3ec0f

-David

P.S. I'm pretty sure that Photoshop CS4 does now have app.system().

[_xbytor_]

>
> You have a good point about the XMPScript API not using the File object. I've logged a feature request bug about this with the XMP team.

Thanks.


>
> You can also raise this issue on the XMP SDK forum:

Will do.


>
> P.S. I'm pretty sure that Photoshop CS4 does now have app.system().

Surprise, sur...

[dfranzen_camera_raw]

I agree that Bridge's app.system() could be better. It's not clear to me how many folks are actually using it, and for what.

Have you tried using an external scripting object to interact with the system or MySQL servers using C or C++? On the surface this may seem like more work than using scripting alone, but I've found the examples in the SDK easy to understand and extend.

-David

[_xbytor_]

> Have you tried using an external scripting object to interact with the system or MySQL servers using C or C++? On the surface this may seem like more work than using scripting alone, but I've found the examples in the SDK easy to understand and extend.

I started working with that SDK when it first came out. I was going to do some
basic interface to XMP SDK in PSCS3 since the ESTK XMPScript dll wouldn't load
correctly in PS. I found the limitations were excessive. The biggest problems
were the inability to define class methods and properties, IIRC. It looked like
that SDK was built to solve a specific type of problem rather than solve the
general problem of providing a complete set of JS<->C/C++ bindings.

I used to do a lot of work with embedded and extendable interpreters (Tcl and
perl, mostly) so I'm not unfamiliar with the technology. I should probably crack
the SDK open again to see if any if the initial shortcomings have been addressed.

-X