You can’t “install” source packages at present. Why do you need them though? Shouldn’t python_devel be enough?
There is no python_devel or python3_devel package listed as far as I can see.
OK, it appears that code can be generated by SWIG quite well. Just playing around with compiler errors right now. Will report back once I have something decent working.
OK So I got both a python and ruby library to compile. Just testing out the right command line to get both simple examples working. Going to bed now, but will report back in 3-4 days once I’ve had time to look at this further.
Nice work! Thanks for looking into that. I’ve been looking at swig (never looked deeply) and of course they implement an interface language like IDL 
You are about to discover CORBA. Hint: it didn’t work.
Also, all of this sounds like it will pretty much need a rewrite of everything.
+1 however on documenting our protocols (BMessage, app_server link, etc) in case someone wants to attempt it. Then they can collaborate with the existing API, at least.
1 Like
Good news all. I have a basic app working. I decided to concentrate on something small - just the BString class and String.h include file.
I now have a working SWIG based wrapper library for Python, and a sample app. I also created a sample app for the beep function, but I don’t have sound on my VM so can’t really test it (it didn’t fail when running though…)
Details in the below README if you want to try it out. Very simple at the moment, but shows the technique can work:-
1 Like
The Binder is explicitly, partially, inspired on CORBA. You can even see it mentioned by Dianne Hackborn. But the concepts were really redesigned on top of the BeOS stuff (ports, etc.). Fuchsia is doing approximately the same thing, since the internals are the spiritual evolution of those in NewOS.
Android works, right? 
In my ideas, the real rewrite would be done on the app_kit and support_kit side. Perhaps we may need to add some new kernel internal (channels?). But then, it’d be incremental development on porting our old code on top of that. Yes it’d not be easy like keep everything, but the Haiku API is relatively small, I think with some common focus (for example having this as focus for R2), I think it can be done.
Note that, I think pushing for innovations is what prevent us getting new devs.
Let’s imagine a situation like that. I program a malware that begins to send invalid messages at random. What protection we have from that? And what happens if an app begin to DOS a server? And suppose I want to keep a client-server protocol working, what does Haiku supply to prevent all of that?
Where I think something like IDL comes into play. Servers can have an interface definition file where:
- Message constants are defined
- Other constraints are defined, like is this message waiting for a response or not? Then we define the reply we expect from a messaging session.
- Are all messages used for IPC? I don’t think so, some message may be forbidden then to do that. How? Simply it is not “public”.
- Our looper is a special looper? Like it communicates with the app_server? Cool, our message interface will allow the protocol to communicate with the app_server.
Keep in mind, something like that can be even done extending the rdef format.
What advantages we get with something on those lines?
- Public and private concepts introduced into messaging/scripting
- A programmer always know how to script an app and what a messaging protocol imply.
- The system know who contact who and why (like Android’s permission to access some capabilities)
- Documentation can be automatically generated
- Everything is much cleaner, to avoid collisions (public) message constants can be assigned uniquely by using a system provided mechanism, we have 2^64 values available right?
- Reduce code duplication
- Improve security and performances. If an app sends strange messages to a server, the server log it: improved debugging.
And I have another tons of advantages, but those should be enough?
And I have another very important thing to point out. How we can protect shared memory? Right now I can in theory access any area and do any funny thing with it. In UNIX this is not a problem, since everything is a file, you can have an ACL on top of it by design. Servers can give access to shared memory only to some processes. Using IDL-like concepts, we can extend areas and have an ACL on top of it. Think of Web+, don’t you think a motivated person could exploit it easily and access system memory?
I hope you see, how it is important we include a mechanism like that on the long term. If we do it carefully, we can also semplify how apps are written, so reduce code duplication, and at the same time give more security.