feat: Adds Reader.from_manifest_data_and_stream along with set_remote_url and set_no_embed.

[gpeacock]

No description provided.

[tmathern]

Is there any chance that the manifest_data could be blank (e.g. or any variation of whatever could be considered blank). Do we need special care around that?

[gpeacock]

This option is allow verifying a sidecar or remote manifest. If we have retrieved a .c2pa manifest store from our cloud or a sidecar, we can pass it in along with an associated asset to see if it verifies. If the manifest_data is not a correctly structured binary .c2pa we will return errors reporting it.
I should add a ticket somewhere to do more type checking at a higher level, If you pass the wrong type of parameter, it will get caught, but the error messages are obscure ones from the binding layer.

[tmathern]

Question: Is this to poison the lock or... ?

[gpeacock]

This is here because the uniffi tool we use to generate python bindings does not support mutable parameters. So we add an internal check to ensure there is only one mutable access at a time.

[dyro]

We could use atomics here in Buidler to get around this eventually, if we end up having to have these binding layers hold on to a Mutex because of the Uniffi requirements of no mut vars as params. Not something that needs to be done for this PR, but it may make our lives easier down the road.

use std::sync::atomic::{AtomicBool, Ordering};

struct Builder {
    no_embed: AtomicBool
}

impl Builder {
    pub fn set_no_embed(&self, value: bool) {
        self.no_embed.store(value, Ordering::Relaxed)
    }
}


fn main() {
    let b = Builder {
        no_embed: AtomicBool::new(true)
    };
    
    
    b.set_no_embed(true);
    
    // note how b, defined above, is not mutable. 
    std::thread::scope(|s| {
        let _ = s.spawn(|| b.set_no_embed(false));
        let _ = s.spawn(|| b.set_no_embed(true));
        let _ = s.spawn(|| b.set_no_embed(false));
    });
}

[crandmck]

Should we add something to the docs (i.e. README) about these new functions?

I'm not sure how much of the API we need to document for each language. These functions are pretty much the same as the ones in Rust. We should spend some time thinking about that.

[dyro]

Looks good! Posted an idea now how to prevent the Mutex in bindings layers, but definitely not required to get this PR in.

[dyro]

We could use atomics here in Buidler to get around this eventually, if we end up having to have these binding layers hold on to a Mutex because of the Uniffi requirements of no mut vars as params. Not something that needs to be done for this PR, but it may make our lives easier down the road.

use std::sync::atomic::{AtomicBool, Ordering};

struct Builder {
    no_embed: AtomicBool
}

impl Builder {
    pub fn set_no_embed(&self, value: bool) {
        self.no_embed.store(value, Ordering::Relaxed)
    }
}


fn main() {
    let b = Builder {
        no_embed: AtomicBool::new(true)
    };
    
    
    b.set_no_embed(true);
    
    // note how b, defined above, is not mutable. 
    std::thread::scope(|s| {
        let _ = s.spawn(|| b.set_no_embed(false));
        let _ = s.spawn(|| b.set_no_embed(true));
        let _ = s.spawn(|| b.set_no_embed(false));
    });
}

[scouten-adobe]

No concerns on the Rust side. I don't know enough Python to review that side.

[gpeacock]

Looks good! Posted an idea now how to prevent the Mutex in bindings layers, but definitely not required to get this PR in.

Thanks for the suggestion. I'd rather not redefine the Builder structure for the Python bindings. But we could look into alternatives if this locking turns out to be an issue.