Tue, 27 May 2014 12:16:45 -0700 bundle2: ignore advisory part with unknown parameters
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 12:16:45 -0700] rev 21626
bundle2: ignore advisory part with unknown parameters Advisory parts are advisory. If a handler exists but does not support the proper parameters, we can safely ignore it. Test has been updated to include this case.
Tue, 27 May 2014 12:01:00 -0700 bundle2: enforce all parameters in a part to be handled
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 12:01:00 -0700] rev 21625
bundle2: enforce all parameters in a part to be handled Once we picked a handler, we check that all mandatory parameter keys are properly supported. If not we raise an exception. We added a test for this case. The code now fails for any part with unknown mandatory parameters. We will ignore such errors for advisory parts in a later changeset.
Wed, 28 May 2014 11:40:07 -0700 bundle2: declare supported parameters for all handlers
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 11:40:07 -0700] rev 21624
bundle2: declare supported parameters for all handlers We now update all existing handlers with the supported parameters information.
Tue, 27 May 2014 11:49:48 -0700 bundle2: make it possible to declare params handled by a part handler
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 11:49:48 -0700] rev 21623
bundle2: make it possible to declare params handled by a part handler If we are to enforce the mandatory aspect of parameter, we need a way to discover what a handler supports. The best option we end up with is this a simple declaration of known parameters at registration time. We simply plug the list of parameters on the function object because Python lets us do that and there is no benefit for a more complicated way. One of the handlers is updated for example and testing.
Wed, 28 May 2014 15:57:23 -0700 bundle2: support transmission of params error over the wire
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:57:23 -0700] rev 21622
bundle2: support transmission of params error over the wire We picked a null character to split each parameter during the transfer. This is fragile if the same character is used in parameter name. However other codes will already behave in a strange way in that case, so we are not introducing any regression. A better format may be picked for the final version of the protocol.
Wed, 28 May 2014 15:53:34 -0700 bundle2: introduce a ``params`` attribute to BundleValueError
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:53:34 -0700] rev 21621
bundle2: introduce a ``params`` attribute to BundleValueError We'll first use it for unsupported mandatory parameters on parts.
Wed, 28 May 2014 15:51:19 -0700 bundle2: introduce a parttype attribute to BundleValueError
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:51:19 -0700] rev 21620
bundle2: introduce a parttype attribute to BundleValueError We will use the Exception for more that just unknown part type.
Tue, 27 May 2014 10:32:07 -0700 bundle2: rename b2x:error:unknownpart to b2x:error:unsupportedcontent
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 10:32:07 -0700] rev 21619
bundle2: rename b2x:error:unknownpart to b2x:error:unsupportedcontent This is a backward compatibility breakage per se. But bundle2 was explicitly flagged as experimental, and this is one an error path anyway. So the worse possible outcome from this change is to still have a crash but with a different message.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip