...
| Expand | ||
|---|---|---|
| ||
We are starting by working with some helpful customers who are willing to share their code from Iguana 6 so we start to get a picture of ‘what is normal?'. What is the set of components and configurations hits 90% of the use cases? |
| Expand | ||
|---|---|---|
| ||
I would be happy to have a conversation with you. Take a step back and think hard about what a plugin or client executable really is. It’s basically a means of allowing a programmer using a language like C# to push a message into an Iguana queue. This is done through a number of layers: C# Code → Stub code → DLL → Proprietary TCP/IP protocol in C++ → Iguana 6 Since IguanaX allows one to write fully fledged TCP/IP servers in theory you could replicate the proprietary TCP/IP protocol and without recompiling the C# code: C# Code → Stub code → DLL → Proprietary TCP/IP protocol in Lua → IguanaX It seems redundant though. In software simpler is always better in terms of less points of failure. This is the architecture I would recommend: C# Code → Native web service call → Web Service component in IguanaX A compromise could be: C# Code → DLL → HTTP(S) calls → Web Service component in IguanaX I think personally the bolded option makes the most sense. It offers the most control and extensibility since additional web service calls can easily be implemented - you’ll have much more control. |