It is my intention to write a client library for the NetFIX protocol and include it in the FIX-Gateway codebase. Currently the 'fix' module that is used in pyEfis is included in the pyAvTools package which is fine but it might make more sense to move that library to the FIX-Gateway repo since the FIX-Gateway client application needs to use these libraries as well. It would avoid some duplication and make testing easier.
To that end I'd also like to redo how the client library works. Currently the client side of the netfix connection tries to maintain a database of the values that are also stored in FIX-Gateway. There are not a lot of values so the memory requirements are not terrible but maintaining the state of the data between the two databases has proven to be an issue. I think it makes more sense to present to the client application an interface that 'looks' like it is accessing a local database but behind the scenes it will simply communicate with the fixgw server and retrieve the information in real time.
Most of the client interaction with the database involves subscriptions to data value changes anyway. That part of the library would simply need to be a collection of the callback functions needed to communicate these changes to the individual client parts that need them. This would result in zero network overhead since the communication would have already taken place to start with.
It is my intention to write a client library for the NetFIX protocol and include it in the FIX-Gateway codebase. Currently the 'fix' module that is used in pyEfis is included in the pyAvTools package which is fine but it might make more sense to move that library to the FIX-Gateway repo since the FIX-Gateway client application needs to use these libraries as well. It would avoid some duplication and make testing easier.
To that end I'd also like to redo how the client library works. Currently the client side of the netfix connection tries to maintain a database of the values that are also stored in FIX-Gateway. There are not a lot of values so the memory requirements are not terrible but maintaining the state of the data between the two databases has proven to be an issue. I think it makes more sense to present to the client application an interface that 'looks' like it is accessing a local database but behind the scenes it will simply communicate with the fixgw server and retrieve the information in real time.
Most of the client interaction with the database involves subscriptions to data value changes anyway. That part of the library would simply need to be a collection of the callback functions needed to communicate these changes to the individual client parts that need them. This would result in zero network overhead since the communication would have already taken place to start with.