Upcoming API/bindings changes

Do not post support requests, bug reports or feature requests. Discuss CEF here. Non-CEF related discussion goes in General Discussion!

Upcoming API/bindings changes

Postby magreenblatt » Wed Jul 03, 2013 5:46 pm

Hi All,

Changes are currently under consideration that will simplify the C API and make it easier to generate bindings for other languages.

Smaller changes include:

1. Use fixed-size types instead of pointer-size types. For example, use int32 or int64 instead of size_t.

2. Standardize on a reduced set of data types. For example, use double instead of float (in C++ and C API) and int32 instead of bool (in C API).

3. Avoid use of incomplete types. For example, use the cef_time_t structure instead of time_t.

4. Provide auto-generated C APIs for all vector and map types. For example, C APIs like cef_string_map.h will be auto-generated for all unique std::map<T1,T2> types. This allows us to use a single opaque handle type for the vector/map in the C API instead of expanding a single C++ argument to two C API arguments (array pointer + size).

5. Standardize on JavaDoc-style comments (use @param, @return, etc).

Larger changes include:

6. Use an XML structure to describe the CEF API including types, enums, structs and interfaces. All language bindings including C++ will be generated from the XML. As part of this effort the python auto-generation implementation will be modularized to support better code re-use.

7. Support single inheritance for CEF interface types. For example, CefV8Value could be split into 4 separate intefaces: CefV8Value, CefV8Object extends CefV8Value, CefV8Function extends CefV8Object, CefV8Array extends CefV8Object.

8. Auto-generate C++ wrapper types for C API structures (CefRect for cef_rect_t, etc). C++-style setters/getters could automatically be generated based on metadata.

9. Support platform-specific interfaces, methods, etc. For example, CefBrowserHost::GetNSTextInputContext() is only used on OS-X but is currently exposed on all platforms.

10. Support interface types that are not ref-counted. For example, the CefDOMDocument object passed to CefDOMVisitor::Visit cannot be used outside of the callback, so CefDOMDocument does not necessarily need to be ref-counted.

11. Simplify the overall structure of the C API interfaces. Currently interface structures are used which must be allocated on the heap and wrapped/type-cast by the C/C++ bindings. This introduces additional memory and performance overhead. The new design will use opaque pointers and functions instead of structures for interfaces implemented by the library. It will use copyable structures (opaque pointer + function pointers) for interfaces implemented by the client. A simplified example:
Code: Select all
// Client interface
struct _cef_client_t {
  void* handle;
  struct cef_life_span_handler_t* (*get_life_span_handler)(void* self);
  ...
} cef_client_t;

// Library interface
struct cef_browser_handle_t;
// Internally copy the cef_client_t struct instead of referencing it.
struct cef_browser_handle_t* cef_browser_create(..., const struct cef_client_t* client, ...);
void cef_browser_reload(struct cef_browser_handle_t* handle);
...


Comments and/or additional suggestions are welcome.

Regards,
Marshall
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: Upcoming API/bindings changes

Postby MichaelSun » Sun Jul 14, 2013 9:56 am

Add sync IPC...
MichaelSun
Techie
 
Posts: 25
Joined: Thu Jun 06, 2013 12:01 am

Re: Upcoming API/bindings changes

Postby magreenblatt » Tue May 05, 2015 5:43 pm

I'm not completely sold on all of the items listed above, but I'll update this thread as specific items are implemented and/or decided upon.

magreenblatt wrote:3. Avoid use of incomplete types. For example, use the cef_time_t structure instead of time_t.

CefZipReader::GetFileLastModified() appears to be the only usage of time_t in the API currently. Filed as https://bitbucket.org/chromiumembedded/cef/issue/1625.

magreenblatt wrote:7. Support single inheritance for CEF interface types. For example, CefV8Value could be split into 4 separate intefaces: CefV8Value, CefV8Object extends CefV8Value, CefV8Function extends CefV8Object, CefV8Array extends CefV8Object.

Inheritance support added in https://bitbucket.org/chromiumembedded/cef/issue/1623.
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm


Return to CEF Discussion

Who is online

Users browsing this forum: No registered users and 17 guests