On 2/7/13 9:13 PM, "Nicholas Kwiatkowski" <nicho...@spoon.as> wrote:
> On Thu, Feb 7, 2013 at 11:18 PM, Alex Harui <aha...@adobe.com> wrote:
>
>> Hi Nick,
>>
>> Just being picky but...
>>
>> 1) I'd never heard of this one before. I looked it up on Dan's blog and
>> saw
>> that Campos said it can be done with ContentCache. If that's true, why do
>> we need this one?
>>
>
> ContentCache and ImageGate have slightly different purposes (and can be
> used together). ContentCache will cache items in memory once they've been
> loaded from the network or disk. ImageGate will cache items from the
> network on disk so you don't have to rely on the network to get them after
> the first time. This is mostly useful for mobile applications (in fact,
> Dan's orgional implementation was mobile specific), where you load images
> from a remote server. I'm in the process of making it much more generic.
> I've also enhanced the component a bit to actually store the cached items
> to disk in the proper directory on iOS so that Apple won't reject any apps
> made with it.
Isn't ContentCache replaceable? Then you could create an alternate
ContentCache that stores images locally instead of needing a whole new
component? Sometimes I think these components get created because Adobe
didn't document something properly.
>
>
>>
>> 2) Why separate assetXXX properties vs using MultiDPIBitmapSource?
>>
>
> I'm still working on it -- and will probably go that direction. My thought
> was to make this a direct drop-in replacement for BitmapImage or Image
> (depending on the use case). MultiDPIBitmapSouce requires multiple DPIs to
> be specified, which I'd like to make optional.
MultiDPIBS has some fallback logic if the URL for a DPI is unspecified.
>
>
>> 4) Finally, is there a reason Dan didn't donate this himself? I'm
>> wondering
>> if we need some paper trail where Dan gives you permission to do the
>> donation. Maybe forward an email from him to the dev list?
>>
>>
> I believe a copy was sent in back in September when I first committed it to
> my whiteboard. He wasn't interested in committing it himself, but did
> release the code as a compatible license.
Even if the license is compatible, Apache generally doesn't want to take
stuff w/o permission. We need to understand if his copyright needs to go in
NOTICES or not. I'll try to remember to look for the email tomorrow.
September is archived on another computer.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
