Picasa?

[Avi Drissman]

The general rule for content is: if it's a web standard thing then it goes in there.

Cool.. but I was looking at https://codereview.chromium.org/13529028/ and even though the media section is web standard, there's now a whole bunch of Picasa parsing code in there: webkit/fileapi/media/picasa/*

I lgtmed since this was only changing things, but this feels weird to me. Do we want to push back here?

[Jochen Eisinger]

I agree that I'm at least a bit surprised about the location of these files.

I guess push back is the wrong term though. We should propose a better location and explain why it's better

-jochen

[Darin Fisher]

+ folks from the CL

I agree.  This code does not belong in the src/webkit/ module.  We should make the fileapi/media/ module sufficiently pluggable so that Chrome can add in such functionality.

Please prioritize this refactoring.

Thanks!

-Darin

[Steve VanDeBogart]

[Tommy Li]

I chatted with Kinuko yesterday. The FileAPI team is refactoring the webkit/fileapi code to make functionality like this pluggable.

Once that lands, I will move out the Picasa specific stuff.

[Steve VanDeBogart]

FYI - From what I heard, Kinoku expects the refactoring to happen in the next few days to a week.

--

Steve

[Darin Fisher]

Does it make sense for you to contribute to that so as to help accelerate the effort?  Or, are you saying that it makes more sense for you to proceed in landing this code in the "wrong" place for now since it'll be easy enough to bulk move it out later?  Aren't you potentially making her job harder by landing code here?

-Darin

[Steve VanDeBogart]

Both the code that has landed and the code in the CL that triggered this is generic Picasa handling code that isn't hooked up yet. i.e. there is no overhead in dealing with it yet.  That being said, we're happy to wait on landing this CL, move out the existing code, or help with the refactor - whatever is easiest for the fileapi team.

[Darin Fisher]

OK, sounds good.  I suggest holding back the CL for now.  When kinuko comes online, she can advise how it may or may not be useful for you guys to help with the refactoring.

Thanks,

-Darin

[Kinuko Yasuda]

Our refactoring move has been a bit slower than the media team's speed, but I think we can land the base part today or tomorrow.  After that I will ask you (Tommy/media folks) to do/help the actual refactoring and code moving.  I expect the actual moving will be fairly easy, as most of the code is independent from other fileapi code.

Having picasa code there is a bit painful (I should have made the point clearer), so if you could hold on the CL that's also very helpful too.

Thanks!

Kinuko

[Darin Fisher]

Sounds good.  Thanks everyone!

[Greg Billock]

Getting a bit off-topic, but the plan I read looks good, Kinuko. Will the Async interface become the pluggable point, then? It'd be really nice to get everything behind that out of webkit/fileapi, I think. Let me know if I can help.

[Kinuko Yasuda]

Thanks Greg.  The Async interface remains the major specialization point, and its factory class (*MountPointProvider, which is responsible for instantiating Async modules for a given type) will become the pluggable point.  This means we'll be able to get everything behind plus its instantiation part (and some more) out of webkit/fileapi :)   I plan to add a chrome-specific entry point in chrome/browser where you can directly hook your MediaGalleries code and insert additional MountPointProviders to fileapi layer (in two or three more patches in my expectation).  Then we'll have fun cleanup time, where I'll ask for your help!