What would you like to see in Philadelphia 2.0.0?

[jvirtanen]

We released Philadelphia 1.0.0 back in 2018. Since then, we have kept improving the project mainly under the hood with a focus on performance.

The next major release, Philadelphia 2.0.0, will allow us to clean up and otherwise improve the library interface. What kind of changes would you like to see in Philadelphia 2.0.0?

[jheusser]

It could be useful if there was a way to provide default values when a FIXValue is null, instead of hand-crafting the null check, such as:

long lastShares = message.valueOf(LastShares).asInt(0);

Obviously this code would not work right now the way valueOf works but just as example.

[jvirtanen]

This is an interesting idea. Perhaps a sentinel value of some sort could be returned instead of null for an unknown field. 🤔

[jvirtanen]

#219 proposes a solution to this.

[jvirtanen]

I would like to update the FIXMessageListener interface to the following form:

/**
 * Receive a message.
 *
 * @param connection the connection
 * @param message a message
 * @throws IOException if an I/O error occurs
 */
void message(FIXConnection connection, FIXMessage message) throws IOException;

The addition of the connection parameter as well as enhancements in the public FIXConnection interface would make the the built-in administrative message handling optional so that an application could provide its own, either simpler or more complete, implementation.

[barorion]

Supporting custom administrative message handling would be very useful, e.g. for applications that has a dedicated thread for incoming messages handling, and another dedicated thread for sending outgoing messages. The built in administrative message handling does not support such design.

[jheusser]

A way to provide a one-pass extraction of all FIXValue instances for a set of tags could also be nice. Currently there is a lot of unnecessary iteration over the same message to extract all the tags necessary via FIXMessage#valueOf.

[jvirtanen]

This is a good point, and I believe something like this can be already implemented on top of the current API.

The Parity FIX Gateway source code contains an example of a single-pass FIXMessage parser. I think something along these lines could be extracted into a reusable class.

[spoerri]

How about rudimentary high availability? E.g. a standby node that could be manually failed over to

[jvirtanen]

Philadelphia does not currently implement any applications itself but rather only provides a library to help implementing applications. What would be the role of the node you are describing? 🙂

[jvirtanen]

By the way, Artio could be another open source project that you might be interested in. It is a FIX protocol implementation as a gateway application (that speaks SBE to business applications) rather than as a library.

[tfmark]

Does Philadelphia support nested/repeating groups?

[jvirtanen]

It supports repeating groups in the sense that both inbound and outbound messages can contain them. To read or write them, however, the application has to do its own bookkeeping.

[mkst]

I imagine supporting repeating groups is a magnitude more complicated than supporting 'flat' messages -- and if there is no demand for it, then why complicate things.

EDIT Realised I was logged in with my work account when posting the original message!

[mhartememx]

MessageHandler.handleResendRequest() in FIXConnection. does not correctly handle the case where the resend request has EndSeqNo == 0.

[jvirtanen]

Thanks! I opened a separate issue on this. 👍🏼

[jvirtanen]

I opened the pull request #185 to fix this. Just as a reminder, the plan is to have the option of custom handling for administrative messages besides the current built-in handling in Philadelphia 2.0.0. Nevertheless, I’m certainly interested to hear about and fix any protocol level quirks like this in the built-in handling. 🙂