Merge LL table wrappers with the ll function

[tapple]

SLua currently has 3 table wrappers over LSL functions:

• llhttp.response wraps ll.HTTPResponse
• llprim.particleSystem wraps ll.LinkParticleSystem
• llprim.setMedia wraps ll.SetLinkMedia

Since these are mostly LSL functions with a fresh coat of paint, they aren't truly new, and might confuse Lua users who are looking for new features. I think it would be preferable to just have the ll function be able to accept either the backwards-compatable list, or the new dictionary. They can be easily distinguished by whether the table keys are numbers or strings

If a caller passes a table with both array and dict parts, it should probably be an error, though, they could be merged. Passing both defeats one of the main reasons for the wrappers in the first-place: typechecking

Full conversation from 2026-07-07 Server User Group

[12:33 PM] Apple Goat: llhttp.request will be in the next lua build. It's a thin wrapper over llHTTPRequest. I would like it to be removed and save the name for a much more object-oriented http library that's lua-exclusive sometime in the next few years. dunno if anyone else has an opinion
[12:34 PM] Harold (haroldcindy): @apple Goat You mean one that optionally uses coroutines or something like that so you can get a response object?
[12:34 PM] Apple Goat: @harold (haroldcindy) coroutines and request/response classes
[12:34 PM] Harold (haroldcindy): hmmm
[12:35 PM] Harold (haroldcindy): @rider Linden What do you think? Unlike the others, there's lots of additional semantics we'd probably want to add to a new HTTP wrapper other than just arg handling
[12:35 PM] Horny Nuzzle: new http wrapper 👀
[12:36 PM] Rider Linden: I like it @harold (haroldcindy) , but I'm not sure when we'd be able to actually do it. It would be a rather large value of "Soon".
[12:37 PM] Rider Linden: We could move the llhttp:request into the ll. space...
[12:39 PM] Suzanna (suzannalinn): i like ll. space having only functions that LSL has
[12:39 PM] Rider Linden: I think I had suggested adding llcom. But there was some resistance to that if I recall.
[12:39 PM] Horny Nuzzle: I think llhttp. would be a fitting compromise
[12:40 PM] Rex Cronon: i think llcomm sounds better:)
[12:40 PM] Rider Linden: I think that is where it is now...
[12:41 PM] Apple Goat: I'd be fine with moving llhttp.request to llcom.httpRequest if better http isn't coming for 2+ years
[12:44 PM] Apple Goat: if better http is coming within 2 years, I'd rather just scrap the llhttp.request wrapper so that there's only 2 http ways, not 3
[12:45 PM] Harold (haroldcindy): Would it be acceptable if ll.HTTPRequest() itself accepted the new dict form as well as the old list-like input form?
[12:46 PM] Rider Linden: The dict form is just another way of expressing the list.
[12:46 PM] Harold (haroldcindy): yeah
[12:46 PM] Apple Goat: @harold (haroldcindy) I'd be fine with that. but then particle and prim media probably should too
[12:48 PM] Rider Linden: I suspect that could be done...

[Rider-Linden]

I would like to leave the two llprim.particleSystem and llprim.setMedia in place, since they do directly impact prims, and have the optional link param.

[tapple]

sounds good. a couple questions:

1. would the ll function still accept a dict? I hope so.
2. would the llprim functions take a list? I hope not.

[Rider-Linden]

Couple of answers:

1. ll function would accept both list and dict I think I can do the coercion under the hood when required.
2. The llprims would take only the dict.

I'd also remove the llhttp.request and just have ll.HTTPRequest take the list or the dict.