Feature request: @getinv extensions
Issue #150
new
This is inspired by helping a customer who had a very flat, very large #RLV which was causing a script to run out of memory when @getinv returned the whole folder content.
@getinvnumber:<folderspec>=channel - would return the number of subfolders
@getinvrange:from;to;<folderspec>=channel - would return the selected range, from and to would work like LSL so from=0 to=-1 would return the whole folder content. Returns should be consistent across multiple calls, implying that the inventory list should be sorted into alpha order before taking the slice (I forget whether it already is with @getinv)
This would allow #RLV browsers to avoid needing to store the whole folder content each time; instead they could only fetch as many entries as they intend to present at a time and fetch a new subset if the script user browses to the next/previous page of items in the folder
Just found this when looking to report an issue/limitation. I provide a wardrobe solution which uses @getinv/@getinvworn to retrieve customers RLV folders for attachable items. I’ve run into a few customers hitting issues which appear to be caused by the retrieved data from @getinvworn. Specifically when they have 45+ or so folders with fairly lengthy names, the response ends up being truncated to 1024 bytes causing data loss.
I’d say something akin to what is described by Chorazin would allow us to get around this limitation. @getinvrange sounds ideal.