Re: [Adobe-source-devel] Finding resources

[Robert D. <rcd...@gm...>]

On Mon, Jun 1, 2009 at 11:51 AM, Foster Brereton <fbr...@ad...> wrote:

>
> The resource system in APL definitely lacks a more robust design; that
> being
> said, it is not used outside of Adobe Begin, so it's limited use has
> prevented further development of it. If you would like to improve it to
> better suit your needs, please feel free. How would you specify additional
> resource directories at the command line for Adobe Begin? The idea is that
> it's a double-clickable app, so I'm missing something here.


It is a unit test, correct? If so, it needs to be executed from the command
line. Any other means of running the unit test, most usually, should be
unsupported. This includes double-clicks. Unit testing, in my opinion, is
normally automated through some form, and double clicking will never be
necessary.


> If the resource directories you are interested in finding (e.g., the
> working
> directory or a common a preferences directory) can be derived from the OS
> (even if it's an OS-specific routine) then I'd think it would be better for
> the app to discover those directories automatically. There are
> platform-specific source directories for both Mac and Windows that the
> resource system would be able to tap into to solve this problem.


I completely agree. However, I apologize that I did not adequately explain
what I was trying to say. Basically, this is why I called them "hints". In
addition to typical assumptions you can make as far as where to search for
resources (e.g. PATH, working directory, containing directory, etc) you
would have another concept called "hints". These are user-specific paths
that are not predictable and thus are specified manually to assist in
finding resources. It simply gives the resource repository some extra places
to look.


> Can you describe a use case where one thread would want a different set of
> resource directories than another? As for the thread safety issue, it
> shouldn't be too hard to turn root_path into a threadsafe type.


It's not that two threads would need a different set of resource directories
than the other. The issue is more specific than that. If one thread tries to
update the root directory while another is accessing that, you have your
classic race condition. It doesn't matter if this use case is practical or
not, the issue should not exist in general. However, as you've already
clarified, APL is deprecated and so is this area of code. I am no longer
concerned with it having this new information.


> As I said before, there's no concerted effort going on inside Adobe to
> improve APL. Occasionally bug fixes will be made and utility code shuffled
> around to make it more accessible to external sources, but most of it is
> unused. You're welcome to work out ways of improving it.


Sorry, this has been a misunderstanding on my part. I was not aware that APL
was essentially deprecated. I guess in that regard, I'm not really familiar
with the roadmap for ASL/APL. The fact of the matter is, there will almost
always be varying implementations for widgets between platforms. Having said
that, I simply assumed APL represented those variations and would remain
around for that reason. ASL seems like the abstractions to me (i.e. the
widget concepts) and APL seems like the implementation of those concepts
(i.e. how a widget is implemented on Windows or Linux). If this is not the
case, I am interested in knowing where these implementations will be located
in the long term.

The only reason why I was commenting on the find_resource() method is
because I was not aware it was deprecated, as I said before. Now that I
know, I do not feel the need to improve it, since it is moot. It will be
removed later on anyway. For now, copying the resources will work until APL
is completely eliminated and a better approach to finding resources becomes
available.

What is the ideal way of locating resources? This seems like something
outside of the scope of ASL. Is it up to the unit test as to how it wishes
to access resources? Perhaps ASL asks for an EVE script through the means of
an input stream? I have a lot to learn in this area. I jumped into CMake not
thinking that I would have to become so familiar with ASL just yet.