Pepper APIs Best Practices when adding interfaces

[Sabin Flo]

Hi,

Is there any document/discussion thread/anything with best practices for defining a Proxy Resource and Host Resource. What sort of context should one keep. 

I am trying to define a new Pepper Api and I am analyzing this. My perception at this point is that the proxy resource should keep as much of the context as possible.

I can see that for the audio_buffer_resource there is no communication with a  renderer/browser resource and no resource created in them, is this assumption correct ?

Also I am having some difficulties in finding how the resources are kept alive and how are they connected to a plugin instance. 

[David Michael]

Can I ask what you're trying to do? Is this for a Chromium-based browser other than Chrome? To be honest, there aren't many APIs we would accept in to upstream Chromium...  so if that's your goal, we should talk about it before you invest too much work.

On Thu, Feb 26, 2015 at 3:01 AM, Sabin Flo <sabin....@gmail.com> wrote:
> Hi,
>
> Is there any document/discussion thread/anything with best practices for
> defining a Proxy Resource and Host Resource.

Not much...  this is a pretty unusual request! This is a good starting point:
http://www.chromium.org/developers/design-documents/pepper-plugin-implementation

> What sort of context should one
> keep.
>
> I am trying to define a new Pepper Api and I am analyzing this. My
> perception at this point is that the proxy resource should keep as much of
> the context as possible.

That's generally correct. Talking to the host side (either in the renderer or the browser) takes an IPC call, so we try to avoid it unless it's necessary.

>
> I can see that for the audio_buffer_resource there is no communication with
> a  renderer/browser resource and no resource created in them, is this
> assumption correct ?

Without looking carefully, that's probably correct. We have a number of resources that are basically data-only and don't need to send/receive messages, and for which we don't need to keep a backing "host" object in the renderer or browser. NetAddressResource is another example.

>
> Also I am having some difficulties in finding how the resources are kept
> alive and how are they connected to a plugin instance.

Resources are ref-counted objects:

https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/shared_impl/resource.h&rcl=1424941780&l=122

...so they're kept alive so long as there's a scoped_refptr pointing to one. That might be some internal Chromium code, or (usually) because the plugin is holding a reference (See PPB_Core.AddRefResource and ReleaseResource).

The code that deals with that is in the ResourceTracker.

All[*] Resources have a PP_Instance associated with them.

[*] I think PPB_MessageLoopResource is the lone exception, since they must be shareable between instances.

HTH

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to native-client-di...@googlegroups.com.
> To post to this group, send email to native-cli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/native-client-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Sabin Flo]

Hi,

Thanks for replying, David.

I initially thought that there is a need for a filesystem api that would give access to different filesytem backends in the browser.

I have noticed that the existent PPB_FileSystem_API gives access to  the HTML5 filesystem backends. I want to be able to access my google drive from a nacl plugin.

I see that there is this PP_FILESYSTEMTYPE_EXTERNAL type but I don't see any support for specific types or for credentials here:
Browser Resource
or here:
Renderer Resource

The question is should I look into extending this API or build another ?
I see that crxfs is built on top of the mentioned filesystem resources but FlashFile is not.