WIP: Issues 30 loadbalancer

[f5yacobucci]

WIP checkpoint for load balancer examples.

#30

[ivanitskiy]

NIT: potentially it is a good use case to "wrap upstream" and see what we can do with a new "wrapped" upstream rust type... not insisting on the current PR.

[f5yacobucci]

I think that's preferable, to wrap it. I've alluded a little to that in the FIXME's. I'm still thinking through how that should look - it's a little complicated to me ATM.

There are a significant number of structures and functions that accept an ngx_http_upstream_t as an argument.

• upstream peers
• upstream nexts
• upstream headers
• upstream locals
• upstream servers
• upstream state

[ivanitskiy]

true, then similar to Bufferalnog these lines:

pub struct NgxHttpUpstream(*mut ngx_http_upstream_t);

impl NgxHttpUpstream {

   /// Create a [`NgxHttpUpstream`] from an [`ngx_http_request_t`].
    pub unsafe fn from_ngx_http_upstream<'a>(r: *mut ngx_http_upstream_t) -> &'a mut NgxHttpUpstream {
        &mut *r.cast::<NgxHttpUpstream>()
    }
    
    /// Returns the underlying `ngx_http_upstream_t ` pointer as a raw pointer.
    pub fn as_ngx(&self) -> *const ngx_http_upstream_t {
        self.0
    }

    /// Returns a mutable reference to the underlying `ngx_http_upstream_t ` pointer.
    pub fn as_ngx_mut(&mut self) -> *mut ngx_http_upstream_t {
        self.0
    }
}

we simply can just have only these 3 methods and in the module example use

let req = unsafe { &mut http::Request::from_ngx_http_request(r) };
// instantiate wrapped upstream..
let u = unsafe{ req.from_ngx_http_upstream(r.upstream_ptr)) };

// and somewhere in the code block where we have a reference to NgxHttpUpstream as `u` we can get a raw pointer  now:
u.as_ngx_mut()

what do you think? and now the biggest question is it ergonomic? your opinion values here as a module developer and is it readable, etc?

additionally, we can try to think about implementing From trait. so we can implicitly pass upstream...
i hope it is more clear what the high-level direction I'm thinking about is. Please challenge me here as I may be wrong.

[f5yacobucci]

I was leaning towards From trait, but need to experiment a little.

I'm hoping a wrapped upstream can help with the get and free peer functions. If that requires another peer wrapper I need to take that into consideration, but I'd like to hide the Rust -> C func-ptr transmute casts if possible, a macro could possibly hide the boiler plate too perhaps. On the other hand, maybe it just requires Some() around the func pointers. Once again, need to experiment a little more.

Update: get and free are already Options. the transmute was unecessary. still looking at an Upstream wrapper - will follow.

[f5yacobucci]

Adding the upstream method should increment the MINOR version.

[ivanitskiy]

based on this: https://rust-lang.github.io/api-guidelines/naming.html then it may be renamed:
ngx_http_conf_upstream_srv_conf_as_mut

[ivanitskiy]

seems to me based on this https://doc.rust-lang.org/std/primitive.pointer.html we can name as ngx_http_conf_upstream_srv_conf_as_ptr or

some ref: https://doc.rust-lang.org/src/core/ptr/const_ptr.rs.html#1629

[f5yacobucci]

Closing and re-opening with split commits and working version.