Conversation
|
Hi @Y-Nak, Thanks for the work on this library! Is this GigE support branch still in the roadmap? In addition is the purpose of the library to provide an FFI interface for GenTL producers (like harvester, or implement a native generic producer (like aravis). From a quick review it looks like the FFI approach, will there be a way to manage several different GenTL.cti producers? |
|
Hi @osiler, thanks for your interest! Yes, it's still on the roadmap! I was quite busy in the last year (new job, relocation to Germany, etc). The purpose of the GenTL implementation is to simply give access to the cameleon via GenTL API.
No, so far. Cameleon can be regarded as a GenTL producer, so there is no plan to manage the different producers in cameleon. |
|
Ok great, so to summarize the cameleon crate will hopefully allow a drop in open source replacement for GenTL producers that are generally provided by hardware manufactures, while also allowing you to create your own GenTL consumers (clients and software). |
|
Yes, it's 100% correct. One of the main purposes of the crate is to let us be free from vendor lock-in. |
I was under the impression that was on the roadmap for |
|
"Add support for |
|
@Y-Nak, just looking at the contributing guide and for some first issues to help me understand the crate so I can potentially help out. In particular I would be interested in the GigE protocols however I have not implemented / contributed to a protocol before. What do you think the best way to proceed is? |
fix #63
test_all.shis passed.fix #{ISSUE_NUMBER}if the corresponding issue exists.## Changelogsection. If the change is for only internal use, please writeNoneto the section.Changelog