On Wed, Mar 27, 2013 at 8:55 AM, Ted Ross <tr...@redhat.com> wrote: > > On 03/25/2013 09:30 AM, Rafael Schloming wrote: > >> On Mon, Mar 25, 2013 at 8:36 AM, Ted Ross <tr...@redhat.com> wrote: >> >> I question the value of having this as part of the API. It seems to me >>> that the Messenger routing table should be part of the configuration of a >>> system (i.e. in a place like /etc/qpid/messenger/, or the Windows >>> Registry, >>> etc.). Eventually, it might be desirable to have an address translation >>> service that can be accessed remotely. I guess I see this translation as >>> being not the concern of the application, but more of the deployment of >>> the >>> application. >>> >>> >>> Initially I was actually going to add the functionality via some kind of >> configuration file as you say. I have a similar conceptual view of the >> functionality as you describe, i.e. it really should only be used as part >> of the deployment/configuration of the messenger, not part of the >> "application work" portion of the API. I ended up going this route for two >> reasons (no pun intended). For starters it was a bit more expedient as I >> didn't have to write some kind of file format parser, but the second, and >> perhaps more important reason, is that I wasn't sure of the implications >> of >> adding dependencies onto files/file systems. I want messenger to be usable >> from embedded devices that might not even have a file system, so I figured >> it would be safer to offer as a pure API. I do think it would be >> appropriate to layer some kind of system integration on top of this API >> just as you describe. >> >> --Rafael >> >> > I agree with your thinking on this. But... > > This brings up the old question of what the purpose of Messenger is. If > it is to be an end-user API, then I think it's too much to ask the user to > provide file parsing capability to load the routing/address-translation > table. Perhaps this should be a downstream-packaging issue, I'm not sure. > For example, Fedora, Ubuntu, Windows, etc. packages could be pre-loaded > with route table loaders appropriate for their environments.
One thing we could do here is to provide some kind of pn_messenger_configure(pn_messenger_t *m, const char *path). This could be conditionally compiled and so would be unavailable if you're on some kind of embedded system that couldn't support it. A key thing here would be that it should only parse the file and call into otherwise public parts of the messenger API, i.e. we would want to ensure that there isn't anything special you could do through the config file that you couldn't also do directly through the API. This could be used for more than just the routing table. We could have a section for the messenger name, and for all the ssl cert configuration as well. We could even provide a build time option to configure some kind of search path to load a default configuration. I would expect the downstream packagers would likely build in the default location/search path that is tailored to the distro. --Rafael
