Open l-n-s opened 7 years ago
Front page will need to have basic torrent filtering by status - if torrent is active, downloading, seeding, paused or finished.
any updates?
@majestrate waiting for #30
Adding torrents directly from postman, with CLI it works, with WEBUI it doesn't
[NFO] 2017-10-24 09:17:51.329920644 -0400 EDT m=+660.156323877 fetching torrent from http://tracker2.postman.i2p/index.php?action=Download&id=23841
[NFO] 2017-10-24 09:18:22.166920168 -0400 EDT m=+690.993323401 no bitfield for YetAnotherBookCollection.zip
[ERR] 2017-10-24 09:18:23.158900363 -0400 EDT m=+691.985303526 failed to fetch: invalid piece
[NFO] 2017-10-24 09:21:51.634137478 -0400 EDT m=+900.460540641 fetching torrent from http://tracker2.postman.i2p/index.php?action=Download&id=39222
[NFO] 2017-10-24 09:22:02.620384961 -0400 EDT m=+911.446788124 no bitfield for OReillyProgrammingEbooks.tar.gz
[ERR] 2017-10-24 09:22:02.764904037 -0400 EDT m=+911.591307131 failed to fetch: invalid piece
[NFO] 2017-10-24 09:22:39.53475913 -0400 EDT m=+948.361162293 fetching torrent from http://tracker2.postman.i2p/index.php?action=Download&id=39222
[NFO] 2017-10-24 09:22:43.215890508 -0400 EDT m=+952.042293601 verify local data for OReillyProgrammingEbooks.tar.gz
[NFO] 2017-10-24 09:22:43.216199486 -0400 EDT m=+952.042602579 OReillyProgrammingEbooks.tar.gz check okay
[NFO] 2017-10-24 09:23:23.307922953 -0400 EDT m=+992.134326116 fetching torrent from http://tracker2.postman.i2p/index.php?action=Download&id=23841
[NFO] 2017-10-24 09:23:29.833678777 -0400 EDT m=+998.660081940 verify local data for YetAnotherBookCollection.zip
[NFO] 2017-10-24 09:23:29.833965266 -0400 EDT m=+998.660368429 YetAnotherBookCollection.zip check okay
which ones were added via webui?
Both. First I'm adding both with Web, it fails. After I add them with Cli.
XD.SwarmStatus returns full bitfield and other information, so that response is huge. For 3 torrents, it transfers >20KB of data for each request. Is this data required?
is 20KB too much?
I mean, for 3 torrents it is 20KB per request, for 300 torrents it will be like 2MB.
API consumer will ideally want information ready for usage - for displaying in UI or whatever. Bitfield is on another level of abstraction somewhere (in my opinion).
BTW, I've already did a layout, some styling and data binding.
Pulled in Knockout.js for data binding - it's lightweight and has cross-browser support even with IE. Also removed Bootstrap and JQuery (using zepto for ajax, or maybe even go Vanilla). It's already looking nice, except needs details for progress bar etc...
Do we need some fancy icons, or keep UI super minimal?
Edit: Actually I have no idea about bitfield, will have a look how other torrent clients do WebUI...
any images would be bundled inside the XD binary, keep any assets minimal if you use any.
what would you do for bitfields in api?
On Wed, Oct 25, 2017 at 12:39:17AM +0000, l-n-s wrote:
I mean, for 3 torrents it is 20KB per request, for 300 torrents it will be like 2MB.
API consumer will ideally want information ready for usage - for displaying in UI or whatever. Bitfield is on another level of abstraction somewhere (in my opinion).
BTW, I've already did a layout, some styling and data binding.
Pulled in Knockout.js for data binding - it's lightweight and has cross-browser support even with IE. Also removed Bootstrap and JQuery (using zepto for ajax, or maybe even go Vanilla). It's already looking nice, except needs details for progress bar etc...
Do we need some fancy icons, or keep UI super minimal?
— You are receiving this because you were mentioned. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread.
Reverse link: [3]unknown
References
Visible links
Reporting on my little research about transmission web API:
hmmm, looking how transmission webui works with RPC. it requests full details of all torrents on the first load, then it requests only some details of recently active torrents it explicitly requests name of fields which it needs in each request... and has "ids" parameter for method - to specify torerent ID, or group of torrents -- like "ids": "recently-active" i think it's reasonable to reduce data transfered via API, cause people may deploy XD on raspberry pi or remote servers...
It doesn't send back full bitfield, only required information for displaying:
{'arguments': {'removed': [],
'torrents': [{'downloadDir': '/home/user/Downloads',
'error': 0,
'errorString': '',
'eta': 2793,
'id': 3,
'isFinished': False,
'isStalled': False,
'leftUntilDone': 1292042240,
'metadataPercentComplete': 1,
'peersConnected': 46,
'peersGettingFromUs': 1,
'peersSendingToUs': 41,
'percentDone': 0.3367,
'queuePosition': 1,
'rateDownload': 473000,
'rateUpload': 0,
'recheckProgress': 0,
'seedRatioLimit': 2,
'seedRatioMode': 0,
'sizeWhenDone': 1947926528,
'status': 4,
'trackers': [{'announce': 'http://bttracker.debian.org:6969/announce',
'id': 0,
'scrape': 'http://bttracker.debian.org:6969/scrape',
'tier': 0}],
'uploadRatio': 0.0027,
'uploadedEver': 1781490,
'webseedsSendingToUs': 0}]},
'result': 'success'}
noted, will review the use of bitfields in API
On Wed, Oct 25, 2017 at 11:17:13AM -0700, l-n-s wrote:
Reporting on my little research about transmission web API:
hmmm, looking how transmission webui works with RPC. it requests full details of all torrents on the first load, then it requests only some details of recently active torrents it explicitly requests name of fields which it needs in each request... and has "ids" parameter for method - to specify torerent ID, or group of torrents -- like "ids": "recently-active" i think it's reasonable to reduce data transfered via API, cause people may deploy XD on raspberry pi or remote servers...
It doesn't send back full bitfield, only required information for displaying:
{'arguments': {'removed': [], 'torrents': [{'downloadDir': '/home/user/Downloads', 'error': 0, 'errorString': '', 'eta': 2793, 'id': 3, 'isFinished': False, 'isStalled': False, 'leftUntilDone': 1292042240, 'metadataPercentComplete': 1, 'peersConnected': 46, 'peersGettingFromUs': 1, 'peersSendingToUs': 41, 'percentDone': 0.3367, 'queuePosition': 1, 'rateDownload': 473000, 'rateUpload': 0, 'recheckProgress': 0, 'seedRatioLimit': 2, 'seedRatioMode': 0, 'sizeWhenDone': 1947926528, 'status': 4, 'trackers': [{'announce': 'http://bttracker.debian.org:6969/announce', 'id': 0, 'scrape': 'http://bttracker.debian.org:6969/scrape', 'tier': 0}], 'uploadRatio': 0.0027, 'uploadedEver': 1781490, 'webseedsSendingToUs': 0}]}, 'result': 'success'}
— You are receiving this because you were mentioned. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread.
Reverse link: [3]unknown
References
Visible links
bitfields removed from RPC
Some notes for future WebUI:
1) Chromium doesn't show button icons 2) needs more space between elements 3) colors are like wtf (opinionated) 4) display how many bytes are already downloaded
the icons are utf-8 emoji, that's probably a system font related issue.
On Mon, Apr 09, 2018 at 01:19:41PM +0000, l-n-s wrote:
Some notes for future WebUI:
1) Chromium doesn't show button icons 2) needs more space between elements 3) colors are like wtf (opinionated) 4) display how many bytes are already downloaded
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/majestrate/XD/issues/31#issuecomment-379748891
Corrected spacing, element positions and more web-safe colors, what do you think?
a bit better
On Thu, Apr 12, 2018 at 09:53:58PM +0000, l-n-s wrote:
Corrected spacing, element positions and more web-safe colors, what do you think?
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/majestrate/XD/issues/31#issuecomment-380955912
tracking webui updates progress