Lee Skillen <lskillen@...>
toggle quoted messageShow quoted text
Great to hear from you - We were thinking the same regarding the dynamic payload/middleware mappings and thought that this patch might be a good stepping stone towards that; a clean-up and centralisation without the necessity to make more drastic changes, if you will. ;-)
If the identifiers were dynamic I suppose a mapping file of sorts would be checked in with the source code - Not sure if it would still be mama.properties format or not, but I guess it essentially has the same information that is hardcoded at the moment. For example (illustrative, not really fully realised) :-
description=Avis Middleware (Elvin Publish/Subscribe)
A reasonable question is, without enumerations, what does the code in the bridges refer to? I suppose it could do it based on any of the three id, name, or library. If a bridge needs to refer to another bridge it would be the same thing - For example, picking the default payload for a middleware bridge. Should that still be delegated to the bridge itself, which then refers to an id, name and/or library, or should it be loaded from the mapping file? I guess backwards compat is a concern for code out there that still refers to enumerations for some bridge-specific hacks or something else. I love APIs. :-)
On 25 February 2014 10:56, Glenn McClements <gmcclements@...>
At first glance the code looks good, and this is nice little feature with no adverse effects that I can think of. My only issue is that if we're tinkering with this area we should:
- Go the whole hog and make payloads completely dynamic, removing the enum dependancy. Something like point OpenMAMA to a directory and it automatically loading all payloads in there, and query the payload on startup for it's identifier, not allowing two
with the same identifier. There's some security issues with this I suppose.
- Make it applicable to middleware (and any future kind of) bridges as well.
Happy to hear other peoples opinion on this.
Just a quick update, it looks like our SMTP server caused the carriage returns - I've modified a version of git-send-email to include the capability to mime encode attachments as base64. Tested and it carries through the patch in verbatim, so I shouldn't be
sending any more patches that look like they came from a Windows machine. ;-) I'll tidy up the git patch and submit it back to git-core next week since it seems useful (and may be useful to others here too). Let me know if you need to me to re-submit the
OpenMAMA patches I've already sent.
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange Group, Inc. (ICE), NYSE Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
Vulcan Financial Technologies
51 Malone Road, Belfast, BT9 6RY
Office: +44 (0)28 95 817888
Mobile: +44 (0)78 41 425152