Add Symfony's Serializer component to core despite Symfony potentially releasing BC-breaking updates after 2.3.

I used the SVN 2.1 branch in the patch, so I switched to the latest stable release - 2.1.2 as 2.1.2-RC2 seems a little out of date.

This patch just adds the Serializer component into the vendor tree, adjusts composer.*, and adds serializer to the namespace auto loader.

+++ b/core/COPYRIGHT.txt
@@ -64,5 +64,6 @@ PHP
+    - Serializer - Copyright (c) 2004 - 2012 Fabien Potencier

I think this is already covered by a general statement about Symfony elsewhere.

Otherwise this is +1 from me.

Re-rolled and removed change to COPYRIGHT.txt.

According to the original RFC, the Serializer component is in the 'least likely to stay backwards compatible' group for the Symfony 2.x cycle. How we handle upgrading Symfony version past 2.3 is still up in the air, but I'd like us to if at all possible.

This would be the first component from that (presumably less mature compared to the DIC, HTTPKernel and other critical components) group we committed to core. It'd be good to get an idea of how deep our API usage of this is likely to be.

Hmm, I think we're going to be pretty reliant on the component for web services and json-ld, and if it's in core then contrib is going to do whatever we want with it.

If it is a part of Symfony 2.3, then it's part of the LTS - so 3 years from mid-to-end 2013 (2016?), and it would be backwards-compatible.

#10: 1802472-10-add-serializer-component.patch queued for re-testing.

3 years is considerably shorter than the expected lifetime of Drupal 8, I'd expect at the very minimum we'd want to shift to the second LTS release even if we find we're not able to follow individual point releases.

#14 sounds reasonable to me. I don't see particular reason we couldn't hold back one component (or fork it) if we find there's an unresolvable problem updating it compared to others.

Patch in #10 looks good, so RTBC. @catch: what else is needed to make a decision on the API stability concern: should this be assigned to Dries, or are you wanting more community discussion first?

Committing this patch, or deciding not to, is a requirement for web services, so I think major task is the correct classification, unless there's been a change to our classification system I'm not aware of, in which case, please correct me.

Retitling for attention.

It seems stupid to reinvent this so I'm ok with this component, especially since Crell is on board.

The approach in #14 makes sense to me.

I'll leave a bit more time for community discussion before committing.

Just to confirm I'm fine with the approach in #14 too and committing on that basis. Dries normally does the commits for new libraries, so assigning to him.

I'm going to tag this with 'revisit before release' so that some time after 2.3 comes out we remember to have a look at upcoming PRs against the component. We'll be using it by then so should be in a good position to see if there's anything which could cause problems at that point.

Alright, committed this to 8.x. Thanks all. Happy with the "revisit before release" tag too.

One thing to note with the core serializer is that its fairly hard to generate format "optimized" output from the same data structure:

Lets say you have the following array structure:

$article = array(
    'authors' => array(
        array(
            'name' => 'Kurt Vonnegut',
            'nationality' => 'USA',
            'books' => array(
                'Player Piano',
                'Slaugherhouse 5',
                'Welcome to the Monkey House',
            )
        ),
        array(
            'name' => 'Johann Wolfgang von Goethe',
            'nationality' => 'Germany',
            'books' => array(
                'Faust',
                'The Sorrows of Young Werther',
            )
        )
    )
);

Using the following code

$encoder = new XmlEncoder();
$serializer = new Serializer(array(), array('xml' => new XmlEncoder(), 'json' => new JsonEncoder()));
$encoder->setSerializer($serializer);
$data = $serializer->serialize($article, $_format);

you will get the following json:

{

    "authors": [
        {
            "name": "Kurt Vonnegut",
            "nationality": "USA",
            "books": [
                "Player Piano",
                "Slaugherhouse 5",
                "Welcome to the Monkey House"
            ]
        },
        {
            "name": "Johann Wolfgang von Goethe",
            "nationality": "Germany",
            "books": [
                "Faust",
                "The Sorrows of Young Werther"
            ]
        }
    ]

}

which is prefect, but the XML will not be good:

<response>
  <authors>
    <name>Kurt Vonnegut</name>
    <nationality>USA</nationality>
    <books>Player Piano</books>
    <books>Slaugherhouse 5</books>
    <books>Welcome to the Monkey House</books>
  </authors>
  <authors>
    <name>Johann Wolfgang von Goethe</name>
    <nationality>Germany</nationality>
    <books>Faust</books>
    <books>The Sorrows of Young Werther</books>
   </authors>
</response>

So for XML you would have to change the name of the keys in the array from 'authors' to 'author' and 'books' to 'book'.

ok good.

Symfony was updated to 2.4 in #2161397: Update to Symfony 2.4.1 so we don't need to revisit this any more.