#saltr (irc2p) | I2P+ 2.9.0-5+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | notbob.i2p | ramble.i2p | drop.i2p | shinobi.i2p | wall.i2p | /msg an op for voice

dr|z3d zzz: I'm tending towards a single combined search with all results displayed in the main view.

dr|z3d Instead of local / postman / both, a single checkbox that enables disables remote results, with the default being off (local only).

zzz so you've flipped from separate page to combo. I may be flipping the other way. While I have it working, not sure I'm happy with it

dr|z3d No, not flipped. Always said the results should be combined in a single table.

dr|z3d Though if you mean x or y, then sure.

dr|z3d I think x or x+y probably works better.

dr|z3d because you're always going to show local results anyway if they're available when you search postman.

zzz ok I thought you were working on remote search being a separate page

dr|z3d no. I don't think there should be any difference in presentation other than the icons displayed in the columns.

dr|z3d minimal change to the UI, minimal changes to the search in terms of user interaction.

dr|z3d we could add an additional transient (?) tr at the top of the table to indicate the result count (4 local, 4 on postman) or somesuch.

dr|z3d status icon -> postman, action icon -> download.

zzz yeah I'm not sure how much jank can be stamped out and how much is inevitable

zzz not just option jank. ajax jank.

dr|z3d I don't do ajax for search right now, so that's not a concern here.

dr|z3d I mean, yeah, it's cool to see results as you type, but I'm not convinced it adds much value in snark.

zzz but just hanging the page load for up to 30 sec or so waiting for a search response is bad too

dr|z3d so, without ajax, it's search term + enter, wait for remote results, display local results instantly, display a status tr at the top of the table while you wait for remote.

dr|z3d you can handle the local refresh with ajax, just not the search itself.

zzz then how do you fill in the remote when you get it?

dr|z3d and when you're searching, to ensure the response is timely, perhaps you override whatever the configured refresh interval is.

zzz oh so you snag it on the next xhr refresh

dr|z3d right

zzz hmm

dr|z3d does that start to sound like less jank? :)

zzz maybe

zzz gonna add some mitsubishis to make it look better

dr|z3d or just use the favicon from postman for remote results.

zzz need mitsubishis for the results rows for whether active or not

dr|z3d oh, you don't display them for local results right now?

zzz I do but remote results is a separate table and renderer

dr|z3d ok

StormyCloud zzz is there a benefit to running additional reseed servers, if the current batch we have are solid?

zzz StormyCloud, while more is better, I don't think we want more than 1 or 2 from a single operator

StormyCloud Roger that

zzz it doesn't give us any meaningful redundancy or diversity

zzz the only benefit is that a certain amount of churn is helpful to avoid firewalls that have blocked the reseeds

dr|z3d if you want to run more reseed servers, host them using the same addresses as now with haproxy on the backend for 100% uptime, StormyCloud

StormyCloud Makes sense, I brainstorming some ideas so just wanted to get your input. Carry away with the fantastic UI discussion, it is z3d favorite thing to talk about.

StormyCloud dr|z3d already do so since you get mad if I dont use haproxy :P

dr|z3d well then we're all good. I don't know where the get mad thing comes from, but hey, it's memeable ;)

StormyCloud You verbally beat me in the DMs :'(

dr|z3d haha, shut up. or you will get hurt. :)

StormyCloud yes of course massa my apologies Ill get back to work.

zzz I think a spinner will make the XHR look less janky but it will be tricky to get right

dr|z3d sure, spinner or progress bar.

dr|z3d or, as I mentioned, if all the results are consolidated in a single table, spinner + tr notification.

dr|z3d I use this for anything that requires a progress bar synced to page load: git.skank.i2p/i2pplus/I2P.Plus/src/branch/master/apps/routerconsole/jsp/js/progressx.js

zzz my remote results table is outside the part of the page that gets XHR-refreshed

dr|z3d another reason to consolidate in the main table :)

zzz i get it but I don't think that's going to work for me. different columns, different info, coming in at different times

dr|z3d not that much different column-wise.

dr|z3d I mean, you just don't display data in any columns that are local only, like ETA, rx/tx

dr|z3d as for the xhr stuff, there's no requirement to pull from a pre-rendered xhr document for remote.

dr|z3d or, you can just create a separate xhr html for remote results.. I do that for the screen logs.

zzz yup thats what I'm doing

dr|z3d that way you can refresh each independently for less jank, as I'm sure you're aware.

zzz one more restart to get the mitsubishis right and I'll show you where I'm at

dr|z3d 10-4

dr|z3d jank-wise, I go a step further to improve overall peformance and UI smoothness.

dr|z3d instead of unconditionally updating the entire xhr region, I check for row changes and only update rows that have changed.

zzz stats.i2p/docs/death.png

dr|z3d death LOL

dr|z3d next you'll be uploading a picture with you wearing skull earrings..

dr|z3d doesn't look too shabby, though uploader and upload date I'd probably omit.

T3s|4 nice to see our beloved cumlord is now immortalized forever ;p

cumlord lmao snark goes emo

zzz when search is active I'm hiding the message box and the three forms at the bottom, think I'll probably do that whether this remote search stuff goes in or not

not_bob cumlord has done a lot of good work for the network.

zzz frankly was not familiar with his work and the nick never inspired me to look further, but good stuff on simp.i2p and #torrents

dr|z3d you might want to migrate configure to a nav button, it's legacy from the original snark.

dr|z3d I'd probably put uploader and upload date on a tooltip on the status icon. Less clutter.

dr|z3d And it moves the results closer to the main view in terms of columns, then.

zzz I'm happy with the added date and uploader columns. cumlord probably happy to see himself in there. RN?

dr|z3d also, anything without seeds I'd exclude.

dr|z3d no sense returning results for dead torrents.

dr|z3d without seeds, or without any peers. whichever.

dr|z3d i.e. if (swarmsize == 0) {continue;}

cumlord not_bob thanks a lot :)

dr|z3d and thinking about it a bit more, the single search form, for me, only makes sense for consolidated search results.

cumlord i've hoped this nick would dampen curiosity

cumlord yeah maybe only alive ones, or some option for filter_id

dr|z3d if I'm going to present search in a separate panel, I'd put the search inputs and results there, then you don't clutter the main search bar, the entire search postman section can be made collapsible, and you can make the postman search form more granular, e.g. search for certain categories of content with a mult-select dropdown.

dr|z3d sure, with a separate search panel you could add that as an option [ ] Include dead torrents in results, max results, etc...

dr|z3d both consolidated results the the main table and a separate panel for postman search have advantages, but I'm tending towards zzz's multi panel display with the search form in the same panel for more granularity and collapsible presentation.

dr|z3d want local search? use the top search bar. want postman search, uncollapse the panel, search using extended search query params.

zzz right now I have filter_id=-1 as an experiment, we'll see

zzz since results are newest-first, most of the dead ones fall off the end

zzz there may be a use case like 'hmm I wonder if I forgot to start up my seed'

dr|z3d [ ] Include dead torrents :)

zzz *** still resisting search options )) ***

zzz even the radio is too much as you've noted

dr|z3d yeah, with the current way you're doing the search form, that makes sense. but with a self-contained postman search panel, it's a different proposition.

zzz yup

zzz anyway it would be rare for dead torrents to drown out the live ones with newest-first

dr|z3d sure, I just think you want to see them at all unless you explicitly ask for them.

dr|z3d *don't

zzz yeah but if I only show live ones then all my mitsubishi work is wasted ((

dr|z3d not if you offer the option to show dead torrents.

dr|z3d but leave it off by default.

zzz only one config I'll probably do, and that's all categories vs default categories, and I'll probably put that on the config page

zzz basically, you want pr0n with your fries or not

dr|z3d I'm tending towards a superset of the search options on postman.

dr|z3d superset in the sense that instead of a single-select dropdown, we do a multi-select so you can pick multiple categories.

zzz pretty sure the API doesn't support that

dr|z3d if they're serving pr0n with fries in your local, that's probably not a very budget-oriented burger you're buying :)

zzz you have 3 choices: default, all, or single

dr|z3d pretty sure postman could be persuaded to extend the api :)

dr|z3d the display order doesn't need a form entry, that can go on the column header icons.

dr|z3d language param could be useful.

dr|z3d and if everything's contained in a collapsible panel, you don't need to mess with the existing display, like removing the screenlogs when you're displaying results. that's bad UX.

dr|z3d it also means that you can keep postman results (cache them) in that panel, and still be able to search locally without removing the results. another UX win.

dr|z3d and with a cache, you can also provide a dropdown for cached results, so you can access your recent history easily.

dr|z3d so yeah, right now everything suggests a self-contained panel for postman search. better UX, cleaner UI.

dr|z3d and of course, as a panel, you can disable it entirely from the configs, if people don't want it at all.

zzz no, you need an order on the form, because he's only serving 100 results max, so you have to supply your order in the fetch

zzz if you just want to sort within the 100, fine

dr|z3d ok, so an order by dropdown as per the tracker, with local sort, sure.

postman guys

zzz and there's no order by best match a la google or ebay

postman dont forget the default category filter

postman which is explained in the doc too

dr|z3d that's part of what we're discussing, postie.

zzz yup I read up on it today

dr|z3d can we extend the api so you can request multiple categories?

postman this should be possible

dr|z3d *thumbs up*

postman since we already have a facility to exclude a list of categories

dr|z3d if we're only getting max 100 results returned, which is reasonable, then it makes sense to be able to filter by multiple categories to make those results as germane as possible.

postman 100 results/per call

postman so this is a real thing ? multiple categories ?

dr|z3d are you caching queries locally?

postman no

postman not these ones

dr|z3d ok. multiple categories? don't see why not. maybe you just want to check for content in the movies, ebooks and documentaries categories, for example.

dr|z3d that way you're not getting spurious results that count against your 100 results per query cap.

dr|z3d re caching, if we cache locally for any given query, that'll reduce load on the server and make reviewing the results more responsive after the first query, obviously with the proviso that we're not caching for too long.

zzz I don't see a need for multiple categories, this is drz's thing

postman i'll think about it after finishing torrent uploads and edit

zzz for the upload, please specify if the b64 is standard or i2p alphabet

postman standard no replacements are needed since its payload within the request and not part of an URI

zzz okey dokey

zzz I dunno if I'd want to do multiple uploads in one, probably want each to succeed or fail on its own

postman i prepare for both

postman if you shoot one, then the HTTP status code will indicate the success

zzz sure, cumlord may want to whip up some mass-upload script

postman if you do multiple, you'll get a 200 and have to parse the result JSON

zzz but from the snark UI probably not

postman probably fine to use single uploads from snark

zzz there;s also the peril of having a huge POST just stall and fail

cumlord i do want to do that :) would be good to see individually if it succeeds or fails

dr|z3d no reason you can't create multiple uploads locally and have them submitted individually. would also be handy to have an auto-resubmit-on-fail feature.

not_bob_afk Auto retry on fail is a very good idea.

postman cumlord: when doing multiple requests in one call (assuming it gets here in one piece ) you'�'�'ll receia a result json, where you can find out how every of the requests did

cumlord that's what i'm thinking, my upload script will hash out everything at once with the metadata, figure i can put that all in a queue to be uploaded one at a time

dr|z3d so we could feasibly submit a few uploads together, and then auto-resubmit only the failed uploads.

cumlord oh, well that changes things

postman yep

zzz if it's all in the background anyway, there's very little value in batching them together, it just increases the chance of failure

postman depending on the type of error: if the request itself was missing mandatory metadata this has to be fixed before a resend

dr|z3d true. so we just need to make sure they get resubmitted in the background if they do fail :)

cumlord nice, bundling a couple together would cut down on api calls and just wait to see which ones fail

dr|z3d we should be able to prevent that locally before it even hits the server, postman.

postman but i will give proper indication what went wrong for every one

cumlord nice it's been useful figuring out the get side

cumlord screenshots and other images could also be bundled somehow if you're into that

postman Blinded message

dr|z3d b64 encode, decode, good idea, cumlord

cumlord could see that being complicated, it's why i don't believe in images much on simp lol

dr|z3d not really, pretty straightforward. attach image(s) in snark, it does the rest.

zzz if you're going to support image upload later then bite the bullet and do multipart now

zzz but multipart would interact poorly with multi-upload

cumlord i meant on db side, just didn't want to deal with it. but yeah, could see that for in-upload select in snark

cumlord maybe could be done with a different kind of operation referencing the hash or torrentid

postman thats what i had in mid

postman *mind

postman when there is actually a torrent and meta information in the db ( will be in the create result set )

cumlord that makes sense to me

cumlord wanna wait for it to exist then add

postman you can followup with a torrent_edit request and add attachments, add torrent to pool(s) and other stuff

postman but as of now that's still in the (hopefully) near future

zzz when you get there, please note in the upload API which fields are required

postman of course :)

postman zzz: there is already some in the latest version of the doc along with an example

zzz yes

RN uploader: nice date:awesome