Add an autoloader providing backwards-compatibility

[jaimeperez]

This PR adds a file that implements and registers an autoloader. This autoloader recognizes the old class names:

• XMLSecEnc
• XMLSecurityDSig
• XMLSecurityKey

and translates them into their appropriate new names including namespaces (\RobRichards\XMLSecLibs\*), creating aliases for every class when it is loaded. For those already using namespaces, this autoloader will have no effect and won't be even run.

This allows users of the library to start using the 2.* branch and start migrating their own code to the new classes using namespaces, at their own pace. We will use it in simplesamlphp/saml2 and simplesamlphp/simplesamlphp for that purpose, for instance. For small code bases it might be ok to just bump the version required in composer.json at the same time you are making the actual changes, but for large code bases it's much easier if the migration can be split in several, smaller commits.

I would definitely consider this as temporary, though. I would set a date in the future (say one year from now, for example), and remove the autoloader then. It's time enough for people to migrate, and backwards-compatibility cannot be kept forever, or you risk people ignoring changes and continuing business as usual.

Of course we would need a new stable release of XMLSecLibs with this, if this gets merged.

Thanks in advance!

[Maks3w]

PSR-0 or PSR-4

[jaimeperez]

In this case, PSR-4, you are right.

[Maks3w]

I think this is an edge case related with your implementation and should your code to be responsible of this.

[jaimeperez]

No, it's not. How could it be providing both the old and the new interface at the same time an edge case specific to my implementation? Anyone using XMLSecLibs and having to migrate from the old classes to the new interface using namespaces will benefit from this, as things will keep working when bumping XMLSecLibs version, and migration can then be gradual.

Besides, this is also beneficial for XMLSecLibs itself. Having both interfaces in parallel at the same time means we don't need to maintain two development branches simultaneously, but just one.

[Maks3w]

For achieve your need the only thing needed is add class aliases in this file https://github.com/robrichards/xmlseclibs/blob/master/xmlseclibs.php No need for more autoloaders

[jaimeperez]

No, not really. Adding an autoloader provides transparency to those not using that file. Remember that file was created to avoid having to load the old monolithic file, or the three of them when the classes were split. If you define the aliases there, then you will have to go back to loading that file manually, every time you want to use this library. And that means, again, huge commits changing lots of files all over the place, together with the bump in the version of XMLSecLibs you depend on. That would be obviously a regression for those who are already using XMLSecLibs with composer and PSR-0.

The only way that could be equivalent to this PR, is telling composer to load it by default, together with the PSR autoloader. But that file is not an autoloader, so it wouldn't really make sense.

[jaimeperez]

By the way, I wonder why the build fails with hhvm. It just stalls and outputs nothing. Maybe it would be a good idea to allow failures there as we had to do in SimpleSAMLphp.