Re: [Adobe-source-devel] Finding resources

[Foster B. <fbr...@ad...>]

On 1/06/09 11:32 AM, "Robert Dailey" <rcd...@gm...> wrote:

> 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.

Adobe Begin isn't a unit-test; it is a GUI front-end and editor for property
model and layout library files. As such it doesn't meet the requirements of
a command-line unit test.

>> 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.

Gotcha. That does clear things up as to what you meant.

>> 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.

OK.

>> 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.

APL isn't essentially deprecated; it's just that there's no continuing
development effort for the widget implementations therein. Internally Adobe
products have their own widget frameworks we're using instead of APL's set,
and externally there hasn't been any contributor who has stepped up to keep
the APL widget set up to date. The code is still useful as the example it
serves, but I wouldn't recommend relying upon the widget set as
production-level code.

That being said, there is still a lot of other utility code in APL that is
immensely useful, which both internal and external parties to Adobe rely
upon.

> 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.

The lack of development effort speaks more to the lack of volunteerism than
the quality or longevity of the code. It's not coming out of APL anytime
soon, it's just not being used. You're free to use it, and if you see
improvements you'd like to make to it you're welcome to do so. Our only
requirement at this point is that Adobe Begin and the APL unit tests
continue to compile and run with at least the same level of functionality as
they do now.

> 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.

For the unit tests any external information is provided to it via command
line. Adobe Begin is a different beast, as I mentioned before.

Blessings,
Foster


-- 
Foster T. Brereton                <ἰχθύς><                Ro 3:21-26
  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov