+devl at freenetproject.org Thanks for the update. Does this mean you're working on a patch for fred? If you send a pull request to fred-staging, I'll review it, but since I'm not familiar with that part of fred, in order to make the review process easier, you must structure the commits better than you have been doing in Winterface.
I have been allowing it so far, because I understand you are developing it from a single-developer-project POV, and there is not an overwhelming amount of contextual code. But this is not the case with fred, so you must be more disciplined. This means: - each commit should do One Thing Only - each commit should be as short as possible - related commits should be grouped together X On 09/07/12 19:33, Pouyan Zaxar wrote: > Hey Ximin, > > for the last 9 days I've been reading source codes of > wicket/atmosphere/fred just to come up with an appropriate solution for > pushing data over websockets and find a solution for HTTP persistent > connection limit. Followings are my observations up to now: > > 1) Current implementation of FProxy* is way too complicated, e.g. > FProxyFetchWaiter(s) can be simply omitted and instead you can just > listen to events generated by ClientEventListener and > ClientGetCallback. Moreover FProxyFetchListener doesn't include any > information about the FreenetURI being fetched, which makes it unusable > if you want to have a single unit which watches progress events > (listens to all changes). > > 2) Current implementation of Atmosphere does not support connection > sharing, however I have been contacting the developers (both of Wicket > and Atmosphere) and it is possible that the upcoming version also > supports connection sharing (as GWT). > > 3)I've been trying to adapt FProxy* the whole time and each time I come > to the conclusion that something is missing or has to be changed to get > it work with current architecture. > > So I thought a reimplementation isn't a bad idea after all. What I > suggest: > > * One ProgressMonitor for each FreenetURI > * One Tracker to manage all ProgressMonitor(s) > * No waiters > * current progress is inquired by page upon render > > You have to consider 2 cases: > > 1) JS/Websocket enabled: Each time a fetch event is happened you just > put it on the EventBus (belongs to Wicket's Atmosphere module) and it > delivers it to all components, which has been registered to receive > asynchronous messages. If in the meantime between page rendering and > asynchronous connection establishment the fetch has been finished, the > page may wait forever to receive a notification from server. To solve > this a JS timeout on the client side must be implemented. > > 2) JS disabled: > Just add meta-refresh. > > This solution would be much easier and would make the following components > obsolete: > > * FProxyFetchWaiter > * List of FProxyFetchResult(s) and FProxyFetchWaiter(s) in > FProxyFetchinProgress > * FproxyEventListener > > > Best > p -- 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/20120709/f5d9bfee/attachment.pgp>
