Lifetimes don't make sense - Lifetimes have to go

[TheQuantumPhysicist]

Hi. First I'd like to thank you for creating this library. Great work. I just have a little complaint, if you will. Maybe I'm misunderstanding something here.

I can see you've created a lifetime for something like CameraList<'a>. I don't think that's necessary. I don't think the lifetime of Camera is necessary either. All lifetimes are covariant, yet they're not related to each other at all... why do they even exist? What are we trying to protect against, exactly?

The problem with this is that if anyone tries to put these objects in a struct, it'll create a self-referencial structs and/or it won't be possible to return any of these objects in methods, because their lifetimes cannot be related to the struct owning them. For example, it's not possible to create a Camera object from a local CameraList... why?

Even worse, because these structs are not send/sync, we can't have a singleton to solve that lifetime problem.

The only trick I have under my sleeve left is to run a dedicated thread with a dedicated event loop and pull frames from that with the main thread being for command and control... a complicated design, if you ask me.

Has anyone succeeded in controlling these structs in one unifying struct under a trait for generic cameras? I don't see how that's possible.

The big question is: Is there a reason I'm missing why these lifetimes exist?

I'm not the ultimate expert in covariance and subtyping... but this design doesn't make sense to me. All these lifetimes have to go! The Drop trait is probably more than enough.

Apologies for the long post.