Hello everyone, I have about two weeks left before the mid term evaluations for this year's GSoC. I must admit that though I had promised to have a buggy version of Packet Transports ready and running by midterm, this has been delayed due to a few reasons.
The past one or two weeks has been spent mainly addressing two new issues/features- 1. We were not happy with transport plugins registering an implemented interface and fred using it. This is because- a) We don't want to run a transport until the user wants to enable it in the settings page. When the user loads a new plugin it is enabled by default. But the user has the option to disable it (for e.g. a particular mode - opennet/darknet). Or we might have a plugin that does multiple tasks. So to handle unnecessary usage, we decided that fred chooses to create an instance of a transport whenever the user wants to use that transport. Also we want to be able to restart transports easily. b) To overcome this and other issues (like an address is needed by a transport for it to bind) we need to use the constructor itself. c) Thus we will now use factory classes. A plugin registers on fred with a factory class that can create an instance of the transport whenever it wants to. This will make things easier for the transport plugin developer. d) A TransportManagerConfig class will now store the bind address of all transports. And the TransportManager will use this to load transports from the plugin. I have made the necessary changes to incorporate this factory class. 2. I began working on this project under the assumption that I would be dealing with IP based transports only. But after discussing on #freenet-dev (apologies) we have decided that it is best to work on a more generic version which can support even abstract transports. So for e.g. a skype based transport plugin would ask fred for an account name to connect to. Our noderef could include a skype account name too. The major hurdle to overcome is the usage of the Peer object which is not sufficiently generic to support such features. So I am working to develop a design that will work with a PluginAddress interface that can be implemented by a plugin the way it wants. toad is currently reviewing my code. The basic design that I have created seems to be fine according to him. But I really need to start working more on the concrete stuff from now on. I believe most design ideas have been covered. On the bright side for me, most of the design has been developed to support streams (TCP) too. So when I get to that part, it must be much easier to complete the tasks. Regards, Chetan Hosmani
