Changing the connection strings?

[vegardlarsen]

I had a discussion with a colleague this morning regarding the connection string format. The goal was the possibility to add certain templated fields to each destination. Say that you want to change the e-mail subject field to make it easier to sort the e-mail, or perhaps you want files stored via ftp to be stored hierarchically in folders: {application}/{version}/{exception}/{timestamp}.zip

We think a lot can be achieved by moving away from connection strings and replacing them with full XML elements, something like this:

<nbug>
    <connection>
        <type>ftp</type>
        <uri>ftp://www.example.com/asdf</uri>
        <username></username>
        <password></password>
        <filenameFormat>Exception_{timestamp}.zip</filenameFormat>
    </connection>
    <connection>
        <type>email</type>
        <server>smtp.example.com</server>
        <port>25</port>
        <username></username>
        <password></password>
        <subject>{version} - {exception} - {method}</subject>
        <template>Hi, an exception was logged: {exception}
            {stacktrace}

            Best regards,
            {applicationName} {version}
        </template>
        <filenameFormat>Exception_{timestamp}.zip</filenameFormat>
    </connection>
    <connection>
        <type>azureblobstorage</type>
        <sharedAccessSignature>1234567890abcdef</sharedAccessSignature>
        <accountName>example</accountName>
        <filenameFormat>{applicationName}/{version}/{exception} {method}/{timestamp}.zip</filenameFormat>
    </connection>
</nbug>

To implement this in the best possible way, I assume we'll change the protocol interface to something like this:

public interface IProtocol<T>
    where T: IProtocolSettings
{
    bool Send(T settings, Stream file);
}

Is this a good idea?

[soygul]

The original CSV connection string idea was to provide users the easiest possible way to create some 'destinations' for their bug reports. It was also chosen so that the 'configurator' tool would easy to maintain.

I can see that this approach would totally eliminate the configuration tool as it would be unnecessarily hard to maintain it (which is OK as no such library has this sort of a tool bundled). I guess XML based configuration/connstr is the way to go for extensibility. I'll branch these latest changes into NBug 2.0 branch as these are begging to get serious.

[Stef569]

This would also allow to replace all the text comparison in the protocols. Like

if (this.UseSsl == "true")

becomes

if (this.useSsl)

How will the xml be loaded? Maybe like this: ProtocolSettingsXmlLoader creates ProtocolSettings

Will there be 1 xml loader for each submission/connection? or will it read all the elements under the connection element as key- value pairs?

Then the mail protocol can query the settings like this

if settings["useSsl"].

A default value is also needed. this can replace all the if isNullOrEmpty in the protocol classes.

if (string.IsNullOrEmpty(this.UseSsl))
{
    this.UseSsl = "false";
}

Maybe like this:

settings.GetBoolean("useSsl", false)

what do you think