The German wing of The Pirate Party just got a few comfy seats in the Berlin state parliament. While the news will sound exciting in and of itself for grass-root movements supporters and ideologists, maybe even more significant would be to mention here that such a development could only happen in (some sort of) a proportional representation democracy, i.e. forget about first taking Manhattan and then taking Berlin, that will never work, but the other way around...
Interesting times ahead or just another protest vote? Time will tell.
Monday, September 19, 2011
Monday, September 12, 2011
Integrating plugins: stage 1
Took a lil' bit longer than i expected (those "little things", you know), but the main p2pOS application now reads the plugin list from a 'plugins' sub-directory and can start plugins.
Essentially, a p2pOS plugin is an application that runs on a client computer (i.e. alongside the main p2pOS application) and which implements a localhost sockets-based communication protocol which allows it to connect to the p2pOS main application (said communication protocol specification is part of the p2pOS API). Thus, because the only requirement for a p2pOS plugin is to implement a sockets-based communication protocol, a plugin can be written in any programming language which provides sockets access, including interpreted languages e.g. python, or tcl/tk, etc.
As the title of this post says, it's only the first stage of the plugin framework that's been implemented so far (specifically having p2pOS detect and run plugins), or, in other words, this is how things look like now:
The next step is to implement the crossed thicK red line(s) in the image below:
So basically, once the crossed-red-lines above will be implemented, a plugin will be able to communicate with another [remote] plugin by tunneling its messages through a p2pOS-managed p2p connection, which in terms of nuts and bolts means something like this:
Finally, because i love screenshots, here's the p2pOS main application starting a plugin...
...and then stopping it:
Essentially, a p2pOS plugin is an application that runs on a client computer (i.e. alongside the main p2pOS application) and which implements a localhost sockets-based communication protocol which allows it to connect to the p2pOS main application (said communication protocol specification is part of the p2pOS API). Thus, because the only requirement for a p2pOS plugin is to implement a sockets-based communication protocol, a plugin can be written in any programming language which provides sockets access, including interpreted languages e.g. python, or tcl/tk, etc.
As the title of this post says, it's only the first stage of the plugin framework that's been implemented so far (specifically having p2pOS detect and run plugins), or, in other words, this is how things look like now:
Finally, because i love screenshots, here's the p2pOS main application starting a plugin...
...and then stopping it:
Saturday, September 3, 2011
Multiple connections are now supported
The P2P network manager now fully supports multiple connections. The image below shows three P2PCommunicator instances running, with user 'a' logging on in the bottom-right window, and users 'b' and 'c' logging on in the other two P2PCommunicator windows; in this setup, the following actions occur (in the listed order):
So the image above shows one user ('a') connected with two other users ('b' and 'c'); now here's how things look like with three peers ('a', 'b', and 'c') all connected to each other:
Together with implementing multiple-connection support, the old disconnect algorithm (which was designed for a single-connection environment) had to be re-written, and it now fully supports multiple connections (btw, properly managing disconnects is no simple feat, took me about a week just to figure out how to do it).
PS
Phew!...
- user 'a' connects to user 'b'
- user 'a' connects to user 'c': user 'a' is now connected to both 'b' and 'c'
- user 'a' sends the message "message from a to b" to user 'b' (i.e. this message is typed in user 'a's window and it appears in user 'b's window)
- user 'a' sends the message "message from a to c" to user 'c' (i.e. this message is typed in user 'a's window and it appears in user 'c's window)
- user 'b' sends the reply "message from b to a" to user 'a' (i.e. this reply message is typed in user 'b's window and it appears in user 'a's window)
- user 'c' sends the reply "message from c to a" to user 'a' (i.e. this reply message is typed in user 'c's window and it appears in user 'a's window)
Together with implementing multiple-connection support, the old disconnect algorithm (which was designed for a single-connection environment) had to be re-written, and it now fully supports multiple connections (btw, properly managing disconnects is no simple feat, took me about a week just to figure out how to do it).
The next two major milestones for the client-side algorithm are:
- implement the plugins architecture (i.e. allow third-party applications running on separate computers to connect to each other using the P2P network as managed by P2P OS); this is no simple thing as it requires defining a P2P direct-link frame structure which should be tunneled by P2P OS, and then implementing a 'DirectP2P' API that will support said frame structure (so this will most likely be a multi-stage task that will keep me busy for several weeks)
- allow relay-based connections between two Non-BEHAVE peers (currently a Non-BEHAVE client can only connect to a BEHAVE-compliant client); i expect relay-based connections to be the last major client-side algorithm update, but you never know...
Just for the fun of it, here's a sample of what i was struggling with late last night:
Phew!...
Subscribe to:
Posts (Atom)