Hi Christian
This is the first thing i thought about.
But it mean that in certain cases the file will be re-loaded
in order to have only the exif part of it decoded.
I would feel like doing things twice coding it that way.
This been sayed, i think the very best of would be to write :
- a specific exif oriented jpg imgIDecoder.
- a specific exif aware imgIImageFrame.
This way, in the same time, i could decode the picture
and its metadata.
But on top of been the most complex way to do i could
imagine, i still don't know how to fetch back that kind of
object from the browser memory (if it is possible of course :)
Maybe everything is stored in the cache, even the decoded
files. While i was scaning thru the XPCOM Cache interface,
i've seen that a cache entry can be either stream based or not.
This would explain why there is both a "cacheElement" and
a "file" member defined in the nsICacheEntryDescriptor ...
Anyway, if that kind of object (imgIImageFrame) is not
supposed to be located in the cache, i don't know from where
i can fetch it back.
On the other hand, if the picture can be stored as a file xor as
an object, then in one case i still have access to the exif part,
and in the other i don't.
Now this is getting realy complex for me :D
I think i'm going to stick with the cache solution for a first step.
But you'r welcome if you feel like to help me sorting my
thoughts about this "better" solution i proposed here ;)
Regards.
Benoit.
PS : the good part is that no matter what happen, i'll allways have to
deal in the end with the raw file to decode it and get exif informations
back.
"Christian Biesinger" <[EMAIL PROTECTED]> a �crit dans le message de
news:[EMAIL PROTECTED]
> On Fri, Dec 24, 2004 at 03:04:52AM +0100, Benoit Lefevre wrote:
> > Unfortunately, the way to use it is still a bite fuzzy. I'm planing
to
> > get a
> > file back from the cache according to a given URI.
>
> That might be problematic, for two reasons:
> o) Not all disk cache entries are stored as separate files
> o) not all cached entities are stored in disk cache at all (esp. HTTPS)
>
> > I have the bad feeling that it's not as simple as having a 1:1
> > mapping between a URI and a key :(
>
> I would suggest using normal necko APIs to load your URI; passing
> LOAD_FROM_CACHE as load flags if desired. This will give you an input
> stream; this may be sufficient for what you want.
>
> (nsIChannel::asyncOpen / nsIChannel::open, after
> nsIIOService::newChannel)
>
>
>
> --
_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom
