[freenet-dev] fproxy-ng first draft and a short roadmap
Hello, I take this as a request: 1. HTLM is not a templating language 2. GWT is just a Framework, not a software architecture 3. "kick-ass design" is not a goal 4. "Code-maintainability and other software-engineering concerns are only secondary here" - definitely not agree Some questions: 1. wysiwyg editor: Which is ? 2. "GWT doesn't allow that..." - ??? Your sources ??? An answer: 1. web design is less than 1% (of charge) of the FProxy rework, please create a static FProxy... it is an excellent and constructive action for FRProxy. The reallity: "As far as I know" here, you have the point. Rgds - Nicolas Hernandez a-n - aleph-networks *CEO* http://www.aleph-networks.com On Tue, Mar 27, 2012 at 9:20 PM, Florent Daigniere < nextgens at freenetproject.org> wrote: > On Wed, Mar 14, 2012 at 06:03:25AM -0500, Ian Clarke wrote: > > On Wed, Mar 14, 2012 at 5:17 AM, Nicolas Hernandez < > > nicolas.hernandez at aleph-networks.com> wrote: > > > > > I have send en email about that. I can fill the decision matrix for > you if > > > you really needs. > > > - Minimalist ui tools > > > - poor production capacity in iterative mode, > > > - developpers knowledge of Wicket, > > > - capacity of using multiple UI with and without js (Lnyx, Web 2.0, > > > Android, ...) > > > > > > are unfavorable compare to GWT > > > > > > > These justifications seem pragmatic. I do agree that the development > cycle > > with Wicket can be a bit slow, at least 4 years ago when I last used it. > > > > Also, you are correct not to underestimate the importance of using a > > familiar tool, it can make a huge difference in development time. > > > > Ian. > > > > They might be pragmatic but they miss the point. We want to change the > templating > engine so that 'web-designers' can use their favourite wysiwyg editor to > help us come up with a kick-ass design. Code-maintainability and other > software-engineering concerns are only secondary here... > > GWT doesn't allow that... The only wysiwyg editors I know about are within > IDEs (Eclipse and Netbeans)... That's not the tool of choice of designers. > You're still writing JAVA code as opposed to plain HTML. As far as I know, > from the list of suggested frameworks, only Wicket fulfills this > requirement. > > see: > https://wicket.apache.org/learn/examples/helloworld.html > > Florent > ___ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120327/0ffc9bec/attachment.html>
[freenet-dev] fproxy-ng first draft and a short roadmap
On Wed, Mar 14, 2012 at 06:03:25AM -0500, Ian Clarke wrote: > On Wed, Mar 14, 2012 at 5:17 AM, Nicolas Hernandez < > nicolas.hernandez at aleph-networks.com> wrote: > > > I have send en email about that. I can fill the decision matrix for you if > > you really needs. > > - Minimalist ui tools > > - poor production capacity in iterative mode, > > - developpers knowledge of Wicket, > > - capacity of using multiple UI with and without js (Lnyx, Web 2.0, > > Android, ...) > > > > are unfavorable compare to GWT > > > > These justifications seem pragmatic. I do agree that the development cycle > with Wicket can be a bit slow, at least 4 years ago when I last used it. > > Also, you are correct not to underestimate the importance of using a > familiar tool, it can make a huge difference in development time. > > Ian. > They might be pragmatic but they miss the point. We want to change the templating engine so that 'web-designers' can use their favourite wysiwyg editor to help us come up with a kick-ass design. Code-maintainability and other software-engineering concerns are only secondary here... GWT doesn't allow that... The only wysiwyg editors I know about are within IDEs (Eclipse and Netbeans)... That's not the tool of choice of designers. You're still writing JAVA code as opposed to plain HTML. As far as I know, from the list of suggested frameworks, only Wicket fulfills this requirement. see: https://wicket.apache.org/learn/examples/helloworld.html Florent
[freenet-dev] (no subject)
We have changed how we do it; Javascript is now completely optional even to change language. Florent On Mon, Mar 19, 2012 at 10:22:34AM +, Florent Daigniere wrote: > > It can be done differently but not using cookies :) > > Anyways, that's only required if you want to change from the language you > configured > your browser to use... not a big deal imo. > > Florent > > On Mon, Mar 19, 2012 at 02:33:02AM +, Ximin Luo wrote: > > Oh, right. Well if all it does is set cookies that can probably be done some > > other way. TBH I'm still in favour of having /%lang%/ in the path. > > > > On 19/03/12 02:13, Steve Dougherty wrote: > > > Leah is correct - Florent added Javascript to set cookies for > > > determining the language served by Apache. > > > > > > On 03/18/2012 10:04 PM, Ximin Luo wrote: > > >> I wasn't aware any previous method used javascript, but we > > >> implemented a non-javascript method quite recently that checks the > > >> client browser's Accept-Language HTTP headers. Have a look at > > >> Steve's thread (in this same mailing list) titled "Spanish > > >> Translation Deployment Complete". > > > > > >> There is JS on the site currently but (I believe) that has nothing > > >> to do with translations. > > > > > >> On 19/03/12 01:04, Leah Hicks wrote: > > >>> I have done my research, although I have to admit wordpress is > > >>> not perfect. If it is /really/ that big of an issue then we will > > >>> simply not use it. And yes I'm aware of the current > > >>> implementation however it uses javascript which will not run if > > >>> users have javascript disabled. If someone can find a workaround > > >>> for that I'm golden. > > >>> > > >>> > > >>> ___ Devl mailing > > >>> list Devl at freenetproject.org > > >>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > > > > > >> ___ Devl mailing list > > >> Devl at freenetproject.org > > >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > ___ > > > Devl mailing list > > > Devl at freenetproject.org > > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > -- > > GPG: 4096R/5FBBDBCE > > https://github.com/infinity0 > > https://bitbucket.org/infinity0 > > https://launchpad.net/~infinity0 > > > > > > > ___ > > Devl mailing list > > Devl at freenetproject.org > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > ___ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Logging subsystem rewrite
There are many problems with https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 : line 25: the static field log should be volatile. It may work now and then but it's broken. Google "double-checked locking" for more info. Either that or synchronize it properly everywhere lines 49-60 - "out" will refer to the parameter, not the static field so you will end up closing the parameter. Also what if Log.out is null? Can't synchronize on null. Line 61: bad synchronization again lines 65-75 Level.ordinal() will compile to a vtable call if you have more than two levels in use across the jvm. lines 100-101: again, if out is null you can't synchronize on it. Besides all this, adding a static dependency will create problems if/when a multi-node simulator or multi-node black box unit tests are written. On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze wrote: > On 27-03-2012 12:51, Martin Nyhus wrote: >> >> On Monday 26. March 2012 00:22:24 Marco Schulze wrote: >>> >>> Working (but incomplete) code is available @ >>> https://github.com/Heiral/fred-staging/tree/logger++ >> >> Please keep in mind that simply deleting Logger will break pretty much >> every >> single plugin out there, so you really should rewrite Logger to call the >> new >> methods in your new logger class. > > Will do. > > >> >> I won't say much about the code since you say you aren't finished, but >> please >> follow the code style of the rest of the code base. > > Apart from the lack of braces, what violates the coding standards? I mean, > compared to the rest of fred code, I use too many blank lines, 80 character > lines, variables are declared at the top of the function and other minor > details. I hope that that isn't a problem. > > >> >> Also, I'm pretty sure you don't want to close the new stream here[0]. > > Fixed. > > >> And the >> locking when you update out isn't sufficient for visibility (either that >> or it >> isn't clear enough why it works IMHO). > > You mean, things like if(out == null) without locking (inside isLoggable())? > In this case, it doesn't really matter as it is meant to be a very quick > check and getting the wrong values don't matter much. > > >> >> [0] https://github.com/Heiral/fred- >> staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 >> ___ >> Devl mailing list >> Devl at freenetproject.org >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > ___ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Logging subsystem rewrite
On Monday 26. March 2012 00:22:24 Marco Schulze wrote: > Working (but incomplete) code is available @ > https://github.com/Heiral/fred-staging/tree/logger++ Please keep in mind that simply deleting Logger will break pretty much every single plugin out there, so you really should rewrite Logger to call the new methods in your new logger class. I won't say much about the code since you say you aren't finished, but please follow the code style of the rest of the code base. Also, I'm pretty sure you don't want to close the new stream here[0]. And the locking when you update out isn't sufficient for visibility (either that or it isn't clear enough why it works IMHO). [0] https://github.com/Heiral/fred- staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
[freenet-dev] GSOC 2012 Tansport Plugin
Also I don't think anyone has agreed to mentor this project. Can somebody let me know if there is a mentor? Thanks On Tue, Mar 27, 2012 at 4:46 PM, Chetan Hosmani wrote: > Thanks for the advice, I think I will find this very necessary if I > get to work on it. It will speed up the process too. > > On Tue, Mar 27, 2012 at 3:10 PM, Ximin Luo wrote: >> One word of advice: if you find the code hard to understand, it is not >> necessarily your fault. IMO the codebase is messy atm. If you have trouble >> with >> any file, use "git log " to find the previous people that >> worked >> on it and go bug them to explain it to you in more human terms. They deserve >> it :p >> >> X >> >> On 27/03/12 10:21, Chetan Hosmani wrote: >>> Hello, >>> >>> I have been idling ?on the IRC channel for quite some time now. The >>> response from freenet is really good. >>> >>> For my GSoC application I have been working on a proposal for the >>> transport plugin. Although the response from freenet is "this is a >>> very hard project", I have tried my best to understand the codebase of >>> freenet and the exact purpose of this project. In particular I have >>> spoken to Arnebab, toad_ and nextgens regarding this assignment and >>> from them have gained a good insight on what needs to be done. >>> >>> Based on their information and some research on the project this is my >>> present standing. Some of it might still be incorrect. >>> >>> Firstly Freenet presently runs extensively on UDP based sockets. The >>> communication happens at several layers and with different mechanisms >>> i.e sockets, streams, reliable packets, UDP, so on... The major >>> problem is that the code has been integrated very tightly. For e.g. >>> NodeCrypto class uses only UDPSocketHandler for communication. So this >>> means that the data cryptography and communication at the transport >>> layer (using UDP in this case) are grouped very tightly. >>> >>> This means that a major refactoring of the code is needed. This task >>> is supposed to be the hard part (where prior freenet experience is >>> needed). >>> Changes will definitely encompass refactoring - Node, NodeCrpyto, >>> UdpSocketHandler and other related dependencies. >>> For this I plan to do a very thorough research and practice on the >>> core functionality of freenet way before the coding period begins, so >>> I know the exact task at hand. >>> I ll obviously be at the mercy of the community. >>> >>> On the other hand a lot of work has been completed. For eg. >>> implementations of OutgoingPacketMangler and IncomingPacketFIlter >>> allow packets defined for any transport protocol. This is also >>> mentioned here - "Last year's work on new packet format should really >>> help although some transports (really small packets e.g. pretending to >>> be Skype) will still need to do their own splitting/reassembly (this >>> should probably happen within the node too, although it should be >>> possible to turn it off). " >>> Streams have better support: >>> https://bugs.freenetproject.org/view.php?id=2214 >>> >>> Secondly once this is achieved, UDP will become an individual >>> transport plugin and similarly the framework will support users to >>> write their own transport plugin. Now this means the cryptography and >>> packet modifications are done in a different level, and hence the >>> developer need not bother about them. As part of the GSoC project I >>> will be required to make this change and also in the process develop >>> TCP transport plugin. >>> Here I think I am more comfortable, and I think my existing knowledge >>> of sockets should get me through. >>> >>> Thirdly, some other objectives as toad_ mentioned as important, >>> include ways to deal with having multiple connections open to the same >>> peer at the same time. Presently haven't thought about this, and don't >>> know that much about freenet for the exact need for this. >>> >>> And apart from this (some confusion regarding this) is implementation >>> of other application level protocols like HTTP, VoIP and so on. Now >>> this can "become" easy if protocols like TCP are enabled. Also as >>> mentioned in the project page is the ability for communications to >>> pretend to be of other protocols. Again I believe it means that an >>> example plugin needs to be developed. >>> This part of the project would spill outside the deadline but it can >>> get direct contribution from the community. >>> >>> The application period has now started, so I ll be turning in mine. >>> But I was hoping I could clarify a few things. >>> >>> I know this is beyond what can be finished in three months. *Please >>> give me your opinion on this proposal and what I should do. * >>> >>> Also as nextgens mentioned, this project would be very hard for me, I >>> would like to know if I should continue researching more or probably >>> give something else a shot. I still have a week to go either way. But >>> I am aware this requires a lot of effort and knowledge and I am
Re: [freenet-dev] Logging subsystem rewrite
There are many problems with https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 : line 25: the static field log should be volatile. It may work now and then but it's broken. Google "double-checked locking" for more info. Either that or synchronize it properly everywhere lines 49-60 - "out" will refer to the parameter, not the static field so you will end up closing the parameter. Also what if Log.out is null? Can't synchronize on null. Line 61: bad synchronization again lines 65-75 Level.ordinal() will compile to a vtable call if you have more than two levels in use across the jvm. lines 100-101: again, if out is null you can't synchronize on it. Besides all this, adding a static dependency will create problems if/when a multi-node simulator or multi-node black box unit tests are written. On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze wrote: > On 27-03-2012 12:51, Martin Nyhus wrote: >> >> On Monday 26. March 2012 00:22:24 Marco Schulze wrote: >>> >>> Working (but incomplete) code is available @ >>> https://github.com/Heiral/fred-staging/tree/logger++ >> >> Please keep in mind that simply deleting Logger will break pretty much >> every >> single plugin out there, so you really should rewrite Logger to call the >> new >> methods in your new logger class. > > Will do. > > >> >> I won't say much about the code since you say you aren't finished, but >> please >> follow the code style of the rest of the code base. > > Apart from the lack of braces, what violates the coding standards? I mean, > compared to the rest of fred code, I use too many blank lines, 80 character > lines, variables are declared at the top of the function and other minor > details. I hope that that isn't a problem. > > >> >> Also, I'm pretty sure you don't want to close the new stream here[0]. > > Fixed. > > >> And the >> locking when you update out isn't sufficient for visibility (either that >> or it >> isn't clear enough why it works IMHO). > > You mean, things like if(out == null) without locking (inside isLoggable())? > In this case, it doesn't really matter as it is meant to be a very quick > check and getting the wrong values don't matter much. > > >> >> [0] https://github.com/Heiral/fred- >> staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 >> ___ >> Devl mailing list >> Devl@freenetproject.org >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > ___ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] GSOC 2012 Tansport Plugin
Thanks for the advice, I think I will find this very necessary if I get to work on it. It will speed up the process too. On Tue, Mar 27, 2012 at 3:10 PM, Ximin Luo wrote: > One word of advice: if you find the code hard to understand, it is not > necessarily your fault. IMO the codebase is messy atm. If you have trouble > with > any file, use "git log " to find the previous people that worked > on it and go bug them to explain it to you in more human terms. They deserve > it :p > > X > > On 27/03/12 10:21, Chetan Hosmani wrote: >> Hello, >> >> I have been idling ?on the IRC channel for quite some time now. The >> response from freenet is really good. >> >> For my GSoC application I have been working on a proposal for the >> transport plugin. Although the response from freenet is "this is a >> very hard project", I have tried my best to understand the codebase of >> freenet and the exact purpose of this project. In particular I have >> spoken to Arnebab, toad_ and nextgens regarding this assignment and >> from them have gained a good insight on what needs to be done. >> >> Based on their information and some research on the project this is my >> present standing. Some of it might still be incorrect. >> >> Firstly Freenet presently runs extensively on UDP based sockets. The >> communication happens at several layers and with different mechanisms >> i.e sockets, streams, reliable packets, UDP, so on... The major >> problem is that the code has been integrated very tightly. For e.g. >> NodeCrypto class uses only UDPSocketHandler for communication. So this >> means that the data cryptography and communication at the transport >> layer (using UDP in this case) are grouped very tightly. >> >> This means that a major refactoring of the code is needed. This task >> is supposed to be the hard part (where prior freenet experience is >> needed). >> Changes will definitely encompass refactoring - Node, NodeCrpyto, >> UdpSocketHandler and other related dependencies. >> For this I plan to do a very thorough research and practice on the >> core functionality of freenet way before the coding period begins, so >> I know the exact task at hand. >> I ll obviously be at the mercy of the community. >> >> On the other hand a lot of work has been completed. For eg. >> implementations of OutgoingPacketMangler and IncomingPacketFIlter >> allow packets defined for any transport protocol. This is also >> mentioned here - "Last year's work on new packet format should really >> help although some transports (really small packets e.g. pretending to >> be Skype) will still need to do their own splitting/reassembly (this >> should probably happen within the node too, although it should be >> possible to turn it off). " >> Streams have better support: https://bugs.freenetproject.org/view.php?id=2214 >> >> Secondly once this is achieved, UDP will become an individual >> transport plugin and similarly the framework will support users to >> write their own transport plugin. Now this means the cryptography and >> packet modifications are done in a different level, and hence the >> developer need not bother about them. As part of the GSoC project I >> will be required to make this change and also in the process develop >> TCP transport plugin. >> Here I think I am more comfortable, and I think my existing knowledge >> of sockets should get me through. >> >> Thirdly, some other objectives as toad_ mentioned as important, >> include ways to deal with having multiple connections open to the same >> peer at the same time. Presently haven't thought about this, and don't >> know that much about freenet for the exact need for this. >> >> And apart from this (some confusion regarding this) is implementation >> of other application level protocols like HTTP, VoIP and so on. Now >> this can "become" easy if protocols like TCP are enabled. Also as >> mentioned in the project page is the ability for communications to >> pretend to be of other protocols. Again I believe it means that an >> example plugin needs to be developed. >> This part of the project would spill outside the deadline but it can >> get direct contribution from the community. >> >> The application period has now started, so I ll be turning in mine. >> But I was hoping I could clarify a few things. >> >> I know this is beyond what can be finished in three months. *Please >> give me your opinion on this proposal and what I should do. * >> >> Also as nextgens mentioned, this project would be very hard for me, I >> would like to know if I should continue researching more or probably >> give something else a shot. I still have a week to go either way. But >> I am aware this requires a lot of effort and knowledge and I am ready >> for that. For now I will try and fix a bug. >> >> Thank you >> >> PS: Comments, including "you don't know shit" or "go watch TV" are welcome :) >> ___ >> Devl mailing list >> Devl at freenetproject.org >> https://emu.freen
[freenet-dev] Logging subsystem rewrite
On 27-03-2012 12:51, Martin Nyhus wrote: > On Monday 26. March 2012 00:22:24 Marco Schulze wrote: >> Working (but incomplete) code is available @ >> https://github.com/Heiral/fred-staging/tree/logger++ > Please keep in mind that simply deleting Logger will break pretty much every > single plugin out there, so you really should rewrite Logger to call the new > methods in your new logger class. Will do. > > I won't say much about the code since you say you aren't finished, but please > follow the code style of the rest of the code base. Apart from the lack of braces, what violates the coding standards? I mean, compared to the rest of fred code, I use too many blank lines, 80 character lines, variables are declared at the top of the function and other minor details. I hope that that isn't a problem. > > Also, I'm pretty sure you don't want to close the new stream here[0]. Fixed. > And the > locking when you update out isn't sufficient for visibility (either that or it > isn't clear enough why it works IMHO). You mean, things like if(out == null) without locking (inside isLoggable())? In this case, it doesn't really matter as it is meant to be a very quick check and getting the wrong values don't matter much. > > [0] https://github.com/Heiral/fred- > staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 > ___ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] GSOC 2012 Tansport Plugin
Hello, I have been idling on the IRC channel for quite some time now. The response from freenet is really good. For my GSoC application I have been working on a proposal for the transport plugin. Although the response from freenet is "this is a very hard project", I have tried my best to understand the codebase of freenet and the exact purpose of this project. In particular I have spoken to Arnebab, toad_ and nextgens regarding this assignment and from them have gained a good insight on what needs to be done. Based on their information and some research on the project this is my present standing. Some of it might still be incorrect. Firstly Freenet presently runs extensively on UDP based sockets. The communication happens at several layers and with different mechanisms i.e sockets, streams, reliable packets, UDP, so on... The major problem is that the code has been integrated very tightly. For e.g. NodeCrypto class uses only UDPSocketHandler for communication. So this means that the data cryptography and communication at the transport layer (using UDP in this case) are grouped very tightly. This means that a major refactoring of the code is needed. This task is supposed to be the hard part (where prior freenet experience is needed). Changes will definitely encompass refactoring - Node, NodeCrpyto, UdpSocketHandler and other related dependencies. For this I plan to do a very thorough research and practice on the core functionality of freenet way before the coding period begins, so I know the exact task at hand. I ll obviously be at the mercy of the community. On the other hand a lot of work has been completed. For eg. implementations of OutgoingPacketMangler and IncomingPacketFIlter allow packets defined for any transport protocol. This is also mentioned here - "Last year's work on new packet format should really help although some transports (really small packets e.g. pretending to be Skype) will still need to do their own splitting/reassembly (this should probably happen within the node too, although it should be possible to turn it off). " Streams have better support: https://bugs.freenetproject.org/view.php?id=2214 Secondly once this is achieved, UDP will become an individual transport plugin and similarly the framework will support users to write their own transport plugin. Now this means the cryptography and packet modifications are done in a different level, and hence the developer need not bother about them. As part of the GSoC project I will be required to make this change and also in the process develop TCP transport plugin. Here I think I am more comfortable, and I think my existing knowledge of sockets should get me through. Thirdly, some other objectives as toad_ mentioned as important, include ways to deal with having multiple connections open to the same peer at the same time. Presently haven't thought about this, and don't know that much about freenet for the exact need for this. And apart from this (some confusion regarding this) is implementation of other application level protocols like HTTP, VoIP and so on. Now this can "become" easy if protocols like TCP are enabled. Also as mentioned in the project page is the ability for communications to pretend to be of other protocols. Again I believe it means that an example plugin needs to be developed. This part of the project would spill outside the deadline but it can get direct contribution from the community. The application period has now started, so I ll be turning in mine. But I was hoping I could clarify a few things. I know this is beyond what can be finished in three months. *Please give me your opinion on this proposal and what I should do. * Also as nextgens mentioned, this project would be very hard for me, I would like to know if I should continue researching more or probably give something else a shot. I still have a week to go either way. But I am aware this requires a lot of effort and knowledge and I am ready for that. For now I will try and fix a bug. Thank you PS: Comments, including "you don't know shit" or "go watch TV" are welcome :)
Re: [freenet-dev] fproxy-ng first draft and a short roadmap
Hello, I take this as a request: 1. HTLM is not a templating language 2. GWT is just a Framework, not a software architecture 3. "kick-ass design" is not a goal 4. "Code-maintainability and other software-engineering concerns are only secondary here" - definitely not agree Some questions: 1. wysiwyg editor: Which is ? 2. "GWT doesn't allow that..." - ??? Your sources ??? An answer: 1. web design is less than 1% (of charge) of the FProxy rework, please create a static FProxy... it is an excellent and constructive action for FRProxy. The reallity: "As far as I know" here, you have the point. Rgds - Nicolas Hernandez a-n - aleph-networks *CEO* http://www.aleph-networks.com On Tue, Mar 27, 2012 at 9:20 PM, Florent Daigniere < nextg...@freenetproject.org> wrote: > On Wed, Mar 14, 2012 at 06:03:25AM -0500, Ian Clarke wrote: > > On Wed, Mar 14, 2012 at 5:17 AM, Nicolas Hernandez < > > nicolas.hernan...@aleph-networks.com> wrote: > > > > > I have send en email about that. I can fill the decision matrix for > you if > > > you really needs. > > > - Minimalist ui tools > > > - poor production capacity in iterative mode, > > > - developpers knowledge of Wicket, > > > - capacity of using multiple UI with and without js (Lnyx, Web 2.0, > > > Android, ...) > > > > > > are unfavorable compare to GWT > > > > > > > These justifications seem pragmatic. I do agree that the development > cycle > > with Wicket can be a bit slow, at least 4 years ago when I last used it. > > > > Also, you are correct not to underestimate the importance of using a > > familiar tool, it can make a huge difference in development time. > > > > Ian. > > > > They might be pragmatic but they miss the point. We want to change the > templating > engine so that 'web-designers' can use their favourite wysiwyg editor to > help us come up with a kick-ass design. Code-maintainability and other > software-engineering concerns are only secondary here... > > GWT doesn't allow that... The only wysiwyg editors I know about are within > IDEs (Eclipse and Netbeans)... That's not the tool of choice of designers. > You're still writing JAVA code as opposed to plain HTML. As far as I know, > from the list of suggested frameworks, only Wicket fulfills this > requirement. > > see: > https://wicket.apache.org/learn/examples/helloworld.html > > Florent > ___ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Stuff to do next
On 2012/03/27 (Mar), at 12:06 AM, Steve Dougherty wrote: > I hope to investigate that this summer as part of Google Summer of > Code! Are there metrics to focus on? The most prominent would be: * CHK success rate from seed nodes should be 100% (or at least no different from a common non-seed node) * there should be no "classes" of seed nodes (e.g. busy ones working & lesser-ones not) There are also less clear indicators: * announcements prematurely ending through some seed nodes * announcement rejection rates * network fracturing/reachability > Would you be willing to contribute analysis, I'd be happy to detail the theory and supply a patch (though both might be more readily available through the list archives)... In a nutshell, it amounts to the "valid" paths (from the seed nodes into the network) by virtue of being traveled by the announcement are consumed by the invalid/fledgling nodes (as that's where they get hooked in). The depth-first notion intends to solve this by replacing the "deep" connections and not the shallow ones that the seed nodes rely upon (and has a strong theoretical analog to insertion requests). > or perhaps even be a mentor? Sorry... insufficient available time. -- Robert Hailey
Re: [freenet-dev] fproxy-ng first draft and a short roadmap
On Wed, Mar 14, 2012 at 06:03:25AM -0500, Ian Clarke wrote: > On Wed, Mar 14, 2012 at 5:17 AM, Nicolas Hernandez < > nicolas.hernan...@aleph-networks.com> wrote: > > > I have send en email about that. I can fill the decision matrix for you if > > you really needs. > > - Minimalist ui tools > > - poor production capacity in iterative mode, > > - developpers knowledge of Wicket, > > - capacity of using multiple UI with and without js (Lnyx, Web 2.0, > > Android, ...) > > > > are unfavorable compare to GWT > > > > These justifications seem pragmatic. I do agree that the development cycle > with Wicket can be a bit slow, at least 4 years ago when I last used it. > > Also, you are correct not to underestimate the importance of using a > familiar tool, it can make a huge difference in development time. > > Ian. > They might be pragmatic but they miss the point. We want to change the templating engine so that 'web-designers' can use their favourite wysiwyg editor to help us come up with a kick-ass design. Code-maintainability and other software-engineering concerns are only secondary here... GWT doesn't allow that... The only wysiwyg editors I know about are within IDEs (Eclipse and Netbeans)... That's not the tool of choice of designers. You're still writing JAVA code as opposed to plain HTML. As far as I know, from the list of suggested frameworks, only Wicket fulfills this requirement. see: https://wicket.apache.org/learn/examples/helloworld.html Florent ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] (no subject)
We have changed how we do it; Javascript is now completely optional even to change language. Florent On Mon, Mar 19, 2012 at 10:22:34AM +, Florent Daigniere wrote: > > It can be done differently but not using cookies :) > > Anyways, that's only required if you want to change from the language you > configured > your browser to use... not a big deal imo. > > Florent > > On Mon, Mar 19, 2012 at 02:33:02AM +, Ximin Luo wrote: > > Oh, right. Well if all it does is set cookies that can probably be done some > > other way. TBH I'm still in favour of having /%lang%/ in the path. > > > > On 19/03/12 02:13, Steve Dougherty wrote: > > > Leah is correct - Florent added Javascript to set cookies for > > > determining the language served by Apache. > > > > > > On 03/18/2012 10:04 PM, Ximin Luo wrote: > > >> I wasn't aware any previous method used javascript, but we > > >> implemented a non-javascript method quite recently that checks the > > >> client browser's Accept-Language HTTP headers. Have a look at > > >> Steve's thread (in this same mailing list) titled "Spanish > > >> Translation Deployment Complete". > > > > > >> There is JS on the site currently but (I believe) that has nothing > > >> to do with translations. > > > > > >> On 19/03/12 01:04, Leah Hicks wrote: > > >>> I have done my research, although I have to admit wordpress is > > >>> not perfect. If it is /really/ that big of an issue then we will > > >>> simply not use it. And yes I'm aware of the current > > >>> implementation however it uses javascript which will not run if > > >>> users have javascript disabled. If someone can find a workaround > > >>> for that I'm golden. > > >>> > > >>> > > >>> ___ Devl mailing > > >>> list Devl@freenetproject.org > > >>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > > > > > >> ___ Devl mailing list > > >> Devl@freenetproject.org > > >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > ___ > > > Devl mailing list > > > Devl@freenetproject.org > > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > -- > > GPG: 4096R/5FBBDBCE > > https://github.com/infinity0 > > https://bitbucket.org/infinity0 > > https://launchpad.net/~infinity0 > > > > > > > ___ > > Devl mailing list > > Devl@freenetproject.org > > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > ___ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Logging subsystem rewrite
On 27-03-2012 12:51, Martin Nyhus wrote: On Monday 26. March 2012 00:22:24 Marco Schulze wrote: Working (but incomplete) code is available @ https://github.com/Heiral/fred-staging/tree/logger++ Please keep in mind that simply deleting Logger will break pretty much every single plugin out there, so you really should rewrite Logger to call the new methods in your new logger class. Will do. I won't say much about the code since you say you aren't finished, but please follow the code style of the rest of the code base. Apart from the lack of braces, what violates the coding standards? I mean, compared to the rest of fred code, I use too many blank lines, 80 character lines, variables are declared at the top of the function and other minor details. I hope that that isn't a problem. Also, I'm pretty sure you don't want to close the new stream here[0]. Fixed. And the locking when you update out isn't sufficient for visibility (either that or it isn't clear enough why it works IMHO). You mean, things like if(out == null) without locking (inside isLoggable())? In this case, it doesn't really matter as it is meant to be a very quick check and getting the wrong values don't matter much. [0] https://github.com/Heiral/fred- staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Stuff to do next
On 2012/03/27 (Mar), at 12:06 AM, Steve Dougherty wrote: > I hope to investigate that this summer as part of Google Summer of > Code! Are there metrics to focus on? The most prominent would be: * CHK success rate from seed nodes should be 100% (or at least no different from a common non-seed node) * there should be no "classes" of seed nodes (e.g. busy ones working & lesser-ones not) There are also less clear indicators: * announcements prematurely ending through some seed nodes * announcement rejection rates * network fracturing/reachability > Would you be willing to contribute analysis, I'd be happy to detail the theory and supply a patch (though both might be more readily available through the list archives)... In a nutshell, it amounts to the "valid" paths (from the seed nodes into the network) by virtue of being traveled by the announcement are consumed by the invalid/fledgling nodes (as that's where they get hooked in). The depth-first notion intends to solve this by replacing the "deep" connections and not the shallow ones that the seed nodes rely upon (and has a strong theoretical analog to insertion requests). > or perhaps even be a mentor? Sorry... insufficient available time. -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] GSOC 2012 Tansport Plugin
gt; Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120327/78733c38/attachment.pgp>
Re: [freenet-dev] Logging subsystem rewrite
On Monday 26. March 2012 00:22:24 Marco Schulze wrote: > Working (but incomplete) code is available @ > https://github.com/Heiral/fred-staging/tree/logger++ Please keep in mind that simply deleting Logger will break pretty much every single plugin out there, so you really should rewrite Logger to call the new methods in your new logger class. I won't say much about the code since you say you aren't finished, but please follow the code style of the rest of the code base. Also, I'm pretty sure you don't want to close the new stream here[0]. And the locking when you update out isn't sufficient for visibility (either that or it isn't clear enough why it works IMHO). [0] https://github.com/Heiral/fred- staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49 ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] GSOC 2012 Tansport Plugin
Also I don't think anyone has agreed to mentor this project. Can somebody let me know if there is a mentor? Thanks On Tue, Mar 27, 2012 at 4:46 PM, Chetan Hosmani wrote: > Thanks for the advice, I think I will find this very necessary if I > get to work on it. It will speed up the process too. > > On Tue, Mar 27, 2012 at 3:10 PM, Ximin Luo wrote: >> One word of advice: if you find the code hard to understand, it is not >> necessarily your fault. IMO the codebase is messy atm. If you have trouble >> with >> any file, use "git log " to find the previous people that >> worked >> on it and go bug them to explain it to you in more human terms. They deserve >> it :p >> >> X >> >> On 27/03/12 10:21, Chetan Hosmani wrote: >>> Hello, >>> >>> I have been idling on the IRC channel for quite some time now. The >>> response from freenet is really good. >>> >>> For my GSoC application I have been working on a proposal for the >>> transport plugin. Although the response from freenet is "this is a >>> very hard project", I have tried my best to understand the codebase of >>> freenet and the exact purpose of this project. In particular I have >>> spoken to Arnebab, toad_ and nextgens regarding this assignment and >>> from them have gained a good insight on what needs to be done. >>> >>> Based on their information and some research on the project this is my >>> present standing. Some of it might still be incorrect. >>> >>> Firstly Freenet presently runs extensively on UDP based sockets. The >>> communication happens at several layers and with different mechanisms >>> i.e sockets, streams, reliable packets, UDP, so on... The major >>> problem is that the code has been integrated very tightly. For e.g. >>> NodeCrypto class uses only UDPSocketHandler for communication. So this >>> means that the data cryptography and communication at the transport >>> layer (using UDP in this case) are grouped very tightly. >>> >>> This means that a major refactoring of the code is needed. This task >>> is supposed to be the hard part (where prior freenet experience is >>> needed). >>> Changes will definitely encompass refactoring - Node, NodeCrpyto, >>> UdpSocketHandler and other related dependencies. >>> For this I plan to do a very thorough research and practice on the >>> core functionality of freenet way before the coding period begins, so >>> I know the exact task at hand. >>> I ll obviously be at the mercy of the community. >>> >>> On the other hand a lot of work has been completed. For eg. >>> implementations of OutgoingPacketMangler and IncomingPacketFIlter >>> allow packets defined for any transport protocol. This is also >>> mentioned here - "Last year's work on new packet format should really >>> help although some transports (really small packets e.g. pretending to >>> be Skype) will still need to do their own splitting/reassembly (this >>> should probably happen within the node too, although it should be >>> possible to turn it off). " >>> Streams have better support: >>> https://bugs.freenetproject.org/view.php?id=2214 >>> >>> Secondly once this is achieved, UDP will become an individual >>> transport plugin and similarly the framework will support users to >>> write their own transport plugin. Now this means the cryptography and >>> packet modifications are done in a different level, and hence the >>> developer need not bother about them. As part of the GSoC project I >>> will be required to make this change and also in the process develop >>> TCP transport plugin. >>> Here I think I am more comfortable, and I think my existing knowledge >>> of sockets should get me through. >>> >>> Thirdly, some other objectives as toad_ mentioned as important, >>> include ways to deal with having multiple connections open to the same >>> peer at the same time. Presently haven't thought about this, and don't >>> know that much about freenet for the exact need for this. >>> >>> And apart from this (some confusion regarding this) is implementation >>> of other application level protocols like HTTP, VoIP and so on. Now >>> this can "become" easy if protocols like TCP are enabled. Also as >>> mentioned in the project page is the ability for communications to >>> pretend to be of other protocols. Again I believe it means that an >>> example plugin needs to be developed. >>> This part of the project would spill outside the deadline but it can >>> get direct contribution from the community. >>> >>> The application period has now started, so I ll be turning in mine. >>> But I was hoping I could clarify a few things. >>> >>> I know this is beyond what can be finished in three months. *Please >>> give me your opinion on this proposal and what I should do. * >>> >>> Also as nextgens mentioned, this project would be very hard for me, I >>> would like to know if I should continue researching more or probably >>> give something else a shot. I still have a week to go either way. But >>> I am aware this requires a lot of effort and knowledge and I am
Re: [freenet-dev] GSOC 2012 Tansport Plugin
Thanks for the advice, I think I will find this very necessary if I get to work on it. It will speed up the process too. On Tue, Mar 27, 2012 at 3:10 PM, Ximin Luo wrote: > One word of advice: if you find the code hard to understand, it is not > necessarily your fault. IMO the codebase is messy atm. If you have trouble > with > any file, use "git log " to find the previous people that worked > on it and go bug them to explain it to you in more human terms. They deserve > it :p > > X > > On 27/03/12 10:21, Chetan Hosmani wrote: >> Hello, >> >> I have been idling on the IRC channel for quite some time now. The >> response from freenet is really good. >> >> For my GSoC application I have been working on a proposal for the >> transport plugin. Although the response from freenet is "this is a >> very hard project", I have tried my best to understand the codebase of >> freenet and the exact purpose of this project. In particular I have >> spoken to Arnebab, toad_ and nextgens regarding this assignment and >> from them have gained a good insight on what needs to be done. >> >> Based on their information and some research on the project this is my >> present standing. Some of it might still be incorrect. >> >> Firstly Freenet presently runs extensively on UDP based sockets. The >> communication happens at several layers and with different mechanisms >> i.e sockets, streams, reliable packets, UDP, so on... The major >> problem is that the code has been integrated very tightly. For e.g. >> NodeCrypto class uses only UDPSocketHandler for communication. So this >> means that the data cryptography and communication at the transport >> layer (using UDP in this case) are grouped very tightly. >> >> This means that a major refactoring of the code is needed. This task >> is supposed to be the hard part (where prior freenet experience is >> needed). >> Changes will definitely encompass refactoring - Node, NodeCrpyto, >> UdpSocketHandler and other related dependencies. >> For this I plan to do a very thorough research and practice on the >> core functionality of freenet way before the coding period begins, so >> I know the exact task at hand. >> I ll obviously be at the mercy of the community. >> >> On the other hand a lot of work has been completed. For eg. >> implementations of OutgoingPacketMangler and IncomingPacketFIlter >> allow packets defined for any transport protocol. This is also >> mentioned here - "Last year's work on new packet format should really >> help although some transports (really small packets e.g. pretending to >> be Skype) will still need to do their own splitting/reassembly (this >> should probably happen within the node too, although it should be >> possible to turn it off). " >> Streams have better support: https://bugs.freenetproject.org/view.php?id=2214 >> >> Secondly once this is achieved, UDP will become an individual >> transport plugin and similarly the framework will support users to >> write their own transport plugin. Now this means the cryptography and >> packet modifications are done in a different level, and hence the >> developer need not bother about them. As part of the GSoC project I >> will be required to make this change and also in the process develop >> TCP transport plugin. >> Here I think I am more comfortable, and I think my existing knowledge >> of sockets should get me through. >> >> Thirdly, some other objectives as toad_ mentioned as important, >> include ways to deal with having multiple connections open to the same >> peer at the same time. Presently haven't thought about this, and don't >> know that much about freenet for the exact need for this. >> >> And apart from this (some confusion regarding this) is implementation >> of other application level protocols like HTTP, VoIP and so on. Now >> this can "become" easy if protocols like TCP are enabled. Also as >> mentioned in the project page is the ability for communications to >> pretend to be of other protocols. Again I believe it means that an >> example plugin needs to be developed. >> This part of the project would spill outside the deadline but it can >> get direct contribution from the community. >> >> The application period has now started, so I ll be turning in mine. >> But I was hoping I could clarify a few things. >> >> I know this is beyond what can be finished in three months. *Please >> give me your opinion on this proposal and what I should do. * >> >> Also as nextgens mentioned, this project would be very hard for me, I >> would like to know if I should continue researching more or probably >> give something else a shot. I still have a week to go either way. But >> I am aware this requires a lot of effort and knowledge and I am ready >> for that. For now I will try and fix a bug. >> >> Thank you >> >> PS: Comments, including "you don't know shit" or "go watch TV" are welcome :) >> ___ >> Devl mailing list >> Devl@freenetproject.org >> https://emu.freenetp
Re: [freenet-dev] GSOC 2012 Tansport Plugin
One word of advice: if you find the code hard to understand, it is not necessarily your fault. IMO the codebase is messy atm. If you have trouble with any file, use "git log " to find the previous people that worked on it and go bug them to explain it to you in more human terms. They deserve it :p X On 27/03/12 10:21, Chetan Hosmani wrote: > Hello, > > I have been idling on the IRC channel for quite some time now. The > response from freenet is really good. > > For my GSoC application I have been working on a proposal for the > transport plugin. Although the response from freenet is "this is a > very hard project", I have tried my best to understand the codebase of > freenet and the exact purpose of this project. In particular I have > spoken to Arnebab, toad_ and nextgens regarding this assignment and > from them have gained a good insight on what needs to be done. > > Based on their information and some research on the project this is my > present standing. Some of it might still be incorrect. > > Firstly Freenet presently runs extensively on UDP based sockets. The > communication happens at several layers and with different mechanisms > i.e sockets, streams, reliable packets, UDP, so on... The major > problem is that the code has been integrated very tightly. For e.g. > NodeCrypto class uses only UDPSocketHandler for communication. So this > means that the data cryptography and communication at the transport > layer (using UDP in this case) are grouped very tightly. > > This means that a major refactoring of the code is needed. This task > is supposed to be the hard part (where prior freenet experience is > needed). > Changes will definitely encompass refactoring - Node, NodeCrpyto, > UdpSocketHandler and other related dependencies. > For this I plan to do a very thorough research and practice on the > core functionality of freenet way before the coding period begins, so > I know the exact task at hand. > I ll obviously be at the mercy of the community. > > On the other hand a lot of work has been completed. For eg. > implementations of OutgoingPacketMangler and IncomingPacketFIlter > allow packets defined for any transport protocol. This is also > mentioned here - "Last year's work on new packet format should really > help although some transports (really small packets e.g. pretending to > be Skype) will still need to do their own splitting/reassembly (this > should probably happen within the node too, although it should be > possible to turn it off). " > Streams have better support: https://bugs.freenetproject.org/view.php?id=2214 > > Secondly once this is achieved, UDP will become an individual > transport plugin and similarly the framework will support users to > write their own transport plugin. Now this means the cryptography and > packet modifications are done in a different level, and hence the > developer need not bother about them. As part of the GSoC project I > will be required to make this change and also in the process develop > TCP transport plugin. > Here I think I am more comfortable, and I think my existing knowledge > of sockets should get me through. > > Thirdly, some other objectives as toad_ mentioned as important, > include ways to deal with having multiple connections open to the same > peer at the same time. Presently haven't thought about this, and don't > know that much about freenet for the exact need for this. > > And apart from this (some confusion regarding this) is implementation > of other application level protocols like HTTP, VoIP and so on. Now > this can "become" easy if protocols like TCP are enabled. Also as > mentioned in the project page is the ability for communications to > pretend to be of other protocols. Again I believe it means that an > example plugin needs to be developed. > This part of the project would spill outside the deadline but it can > get direct contribution from the community. > > The application period has now started, so I ll be turning in mine. > But I was hoping I could clarify a few things. > > I know this is beyond what can be finished in three months. *Please > give me your opinion on this proposal and what I should do. * > > Also as nextgens mentioned, this project would be very hard for me, I > would like to know if I should continue researching more or probably > give something else a shot. I still have a week to go either way. But > I am aware this requires a lot of effort and knowledge and I am ready > for that. For now I will try and fix a bug. > > Thank you > > PS: Comments, including "you don't know shit" or "go watch TV" are welcome :) > ___ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature ___
[freenet-dev] GSOC 2012 Tansport Plugin
Hello, I have been idling on the IRC channel for quite some time now. The response from freenet is really good. For my GSoC application I have been working on a proposal for the transport plugin. Although the response from freenet is "this is a very hard project", I have tried my best to understand the codebase of freenet and the exact purpose of this project. In particular I have spoken to Arnebab, toad_ and nextgens regarding this assignment and from them have gained a good insight on what needs to be done. Based on their information and some research on the project this is my present standing. Some of it might still be incorrect. Firstly Freenet presently runs extensively on UDP based sockets. The communication happens at several layers and with different mechanisms i.e sockets, streams, reliable packets, UDP, so on... The major problem is that the code has been integrated very tightly. For e.g. NodeCrypto class uses only UDPSocketHandler for communication. So this means that the data cryptography and communication at the transport layer (using UDP in this case) are grouped very tightly. This means that a major refactoring of the code is needed. This task is supposed to be the hard part (where prior freenet experience is needed). Changes will definitely encompass refactoring - Node, NodeCrpyto, UdpSocketHandler and other related dependencies. For this I plan to do a very thorough research and practice on the core functionality of freenet way before the coding period begins, so I know the exact task at hand. I ll obviously be at the mercy of the community. On the other hand a lot of work has been completed. For eg. implementations of OutgoingPacketMangler and IncomingPacketFIlter allow packets defined for any transport protocol. This is also mentioned here - "Last year's work on new packet format should really help although some transports (really small packets e.g. pretending to be Skype) will still need to do their own splitting/reassembly (this should probably happen within the node too, although it should be possible to turn it off). " Streams have better support: https://bugs.freenetproject.org/view.php?id=2214 Secondly once this is achieved, UDP will become an individual transport plugin and similarly the framework will support users to write their own transport plugin. Now this means the cryptography and packet modifications are done in a different level, and hence the developer need not bother about them. As part of the GSoC project I will be required to make this change and also in the process develop TCP transport plugin. Here I think I am more comfortable, and I think my existing knowledge of sockets should get me through. Thirdly, some other objectives as toad_ mentioned as important, include ways to deal with having multiple connections open to the same peer at the same time. Presently haven't thought about this, and don't know that much about freenet for the exact need for this. And apart from this (some confusion regarding this) is implementation of other application level protocols like HTTP, VoIP and so on. Now this can "become" easy if protocols like TCP are enabled. Also as mentioned in the project page is the ability for communications to pretend to be of other protocols. Again I believe it means that an example plugin needs to be developed. This part of the project would spill outside the deadline but it can get direct contribution from the community. The application period has now started, so I ll be turning in mine. But I was hoping I could clarify a few things. I know this is beyond what can be finished in three months. *Please give me your opinion on this proposal and what I should do. * Also as nextgens mentioned, this project would be very hard for me, I would like to know if I should continue researching more or probably give something else a shot. I still have a week to go either way. But I am aware this requires a lot of effort and knowledge and I am ready for that. For now I will try and fix a bug. Thank you PS: Comments, including "you don't know shit" or "go watch TV" are welcome :) ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Stuff to do next
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I hope to investigate that this summer as part of Google Summer of Code! Are there metrics to focus on? Would you be willing to contribute analysis, or perhaps even be a mentor? Steve Dougherty On 03/26/2012 01:04 PM, Robert Hailey wrote: > > On 2012/03/24 (Mar), at 6:24 PM, Evan Daniel wrote: > >> I'd add one to that list. > > So long as we're talking "wish list"... you might consider > investigating (or at least seriously considering) my theory that > the shallow-first announcement implementation (current) applies a > dis-integrating force to the network topology, and that > reply-limited-depth-first announcements > (implemented,tested,simulated) are the best thing since sliced > bread! > > -- Robert Hailey > > > > > > ___ Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPcUrRAAoJECLJP19KqmFuiKwQANB3qveb0G0Egx8ER9fR2d+k uBPkul4nCX2RI3B6Q3XvBDLiNCQFmm399DqZ/jfME5/GxbYFfxL5dlLpv4RT8I3E SPjDvMkxd6HmKur9Ur3wwqg6yTIGZUL5SshOQWYEjIdQHVBbW8zmMiZs0h0XsDO1 292UfCqE8CHyV/+EM2JtYsU2qymmSMoWyHQekq+AU0v17bQYWSSzN254ntEsTnT3 QkI7IqjwKkd8YSEnSnHYdYiOXPw3tWypYAJMX3ZPRJBpoAKvTRvsW1MlqCwCTDx0 qbJICoC1tPuVTkE21Bee3Z9UFsJ+9NRNj8DGc7f7bOnlyxtrT5vvKXmbZZJrs/iR g9k2zUAZzMXc9ic/hM/kB/JMzqkOnHwOuye2loyfeN3KY028I+5I8uB+nFHl0VeU LgX6VyLOY+CmDIaQ+A8YUAjAltIIoY+H39Gm/VIfdZrhqeQJnV6HFI+A7b0VUBfC wc8ytaMHOqbGWzULsQiqZJITVa1WNOOciMg/y2YTAya457jvq1uJX9xiHzC5Qymg glT5GsM7j4pL3bQXsmkM2e8WhiR2K5XfEEKv7D/D+zuNwm9JNaDJ76Eq7u50udT2 jIV+eKSpWicku/WJT2SF2wy09mDjE+UMZPoxNQw+xNAmtTVr0HWbqyLmAkQVBM+Y Ohdg39DEnnIJuyzAhoCC =x6wB -END PGP SIGNATURE-
