I didn't look at other places, but I think it is too bad that this is a "fixed" list, there are still problems such as symfony/swiftmailer-bundle#217. So if your mail provider / transport is not implemented here, you can't have a dsn-like custom transport.

I could be wrong though, and that'd be great. :}

wow, lots of negative statements here :( what would be great? you didn't explain your idea? on my side, I don't know how this list could be otherwise than fixed.

Not a negative comment, it's just something I would have liked to have. :}

I would have liked something like an application of the strategy design pattern, e.g have a bunch of transports (as we have now), which each tells if they support a host / a scheme (a dsn actually), so I can register any transport and use it through its DSN.

E.g for the mailjet thing I linked, have the possibility to use mailjet://... or api://mailjet.... at least. Currently (if I understood it right), you can't and are bound to use one of the supported transports...

Once again, I may be wrong. Anyway, even without that, the component is awesome. :}

You mean like a factory strategy? I agree, but this is more about usage without the Framework I guess done a helper class rather than something that is fully concrete.

Maybe the static method can be kept for the standalone but allow the registering of other transporters. Like https://github.com/rollerworks/search/blob/master/lib/Core/Loader/InputProcessorLoader.php#L46

Yep, sorry I meant the factory strategy indeed.