Using Mojo outside of Chromium

[Ravikiran R]

Hello,

We find Mojo to be a very compelling IPC, considering how well we can communicate cross process with a strongly typed interface.

Based on investigation we found the C++ bindings of Mojo has only one dependency on Chromium: //base lib.

Can anyone guide us here

1. Is there an independent mojo based solution outside of chromium

2. If 1. is not available, do you see any issues in pulling out Base and Mojo and compiling them independently outside of chromium.

We also see that the C++ bindings generator uses a few python scripts to parse and generate the required bindings based on *.mojom file.  (We can customize our build script do that).

Reading the docs on mojo, I found that it is structured to be "embeddable". But just could not find if there is an independent mojo repo that can be cloned and built on it's own.

regards,

Ravi

[Ravikiran R]

Hello,

I did go through some of the older messages in this group. 

There seems to be enough interest in Mojo and a limited version of Base (for C++ bindings) to be forked out.

Looks like most people have their own copy of base both internally at google and outside. (Is this a fair statement ??) 

Should we even attempt to create an open source project and hopefully the community (some of us are eager for this) will help carry (including porting latest changes from base) this forward.

regards,

Ravi

[Darin Fisher]

Hi there,

The system was designed with the idea of being modular and reusable. However, we haven't had projects that really need that, so we have kept it simple. As you note, the core system does have a dependency on //base. The generated C++ bindings also have a dependency on //base. That said, you could modify the C++ bindings generator to eliminate that dependency if you wanted. That way consumer code wouldn't need to depend on //base.

A note about depending on //base: //base is not designed to have a stable API. As with many of the libraries in Chromium, they are optimized for Chromium's needs where ease of modification of the code and interfaces is desirable. This means you should be careful about building code that depends on //base. If you ever want to update to a newer //base (to take important bug fixes, say), then you may find it complicated to adopt the new //base since so many interfaces may have changed.

The above is why you might consider creating a forked variant of the C++ bindings generator that does not emit bindings that depend on //base. Then you would have an easier time taking new snapshots of both //mojo and //base since you will be insulated from the churn of //base. (The //mojo core API is designed for stability on the other hand.)

Cheers,

-Darin

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/ad0c1faf-881b-4a7e-ae2c-1cff0043c8ecn%40chromium.org.