Protocols (like COM interfaces) for PL_blob_t

[ds84182]

Queryable protocols would allow cross-extension interop using common interfaces. SWI Prolog could declare built-in protocols for debug printing blobs, byte array access, etc. New protocols could be introduced in newer versions of SWI Prolog without breaking backwards compatibility.

Similar to COM, PL_blob_t could gain a method to query for a protocol by some sort of "GUID" atom. If a blob does not implement a protocol it returns NULL.

---

As an example, a protocol for fetching a byte array from a blob could be defined as (Rust syntax):

pub struct RawBlob {
  /// The pointer to the blob's data.
  ///
  /// This is managed by SWI Prolog for copied blobs.
  pub ptr: *mut c_void,
  /// The length of the blob's data, for copied blobs.
  ///
  /// The length is unused by SWI Prolog for non-copy blobs.
  pub len: usize,
}

pub struct RawBytes {
  ptr: *const u8,
  len: usize,
}

pub struct BytesProtocol {
  /// Returns the bytes from the blob's data payload.
  pub bytes_of: unsafe extern "C" fn(Atom) -> RawBytes,
}

Then various types of blobs containing bytes could be defined. e.g. a blob for mmap'd data or large chunk of externally managed memory.

[JanWielemaker]

Thanks. The SWI-Prolog issue list is more for bugs. Discussion is primarily on https://swi-prolog.discourse.group/

I see some potential. One could also consider implementing a blob type that supports protocols?

[ds84182]

Thanks. The SWI-Prolog issue list is more for bugs. Discussion is primarily on https://swi-prolog.discourse.group/

Ah understood, I'll also cross-post there when I get a chance.

I see some potential. One could also consider implementing a blob type that supports protocols?

A singular blob type has to share the same handlers for acquire & release, and the registration of that blob type is unclear (does each library attempt to register it?).

Right now I'm experimenting with this idea by adding an extra flag to PL_blob_t and then storing the query function in the unused padding field. It seems like a good place to extend the type without changing the size of the structure.

[JanWielemaker]

A singular blob type has to share the same handlers for acquire & release

This blob can proxy to the user blob. That is, if I recall correctly, also what the C++ interface does.

the registration of that blob type is unclear

That is true. The only reliable way would be to define the intermediate blob type in a shared object. That can become a deployment nightmare.

then storing the query function in the unused padding field.

That is what it is meant for 😄 I'll wait and see what happens ...