-
Hans Dieter Pearcey
OpenSourcery Alumnus
A while ago, I talked about my plans for Catalyst-Action-REST, and since then I've made some progress on refactoring to use roles instead of classes. Unfortunately, I've been stalled for the last few weeks, and I could use a nudge to get back on track.
My brain is stuck, basically, on naming issues. This feels a little silly and trivial, but it's something I've run aground on twice now, so I need to fix it somehow. The biggest problem is "serialize" -- Catalyst-Action-REST uses it both as a generic name for "things that either serialize or deserialize" and specifically for "things that serialize" (that is, "convert data to formatted text"). This means I end up wanting to use it to describe a bunch of things:
You can see the results of this sort of naming confusion in the current code on github: Catalyst::ActionRole::SerializeFormat is a pretty goofy namespace.
In my previous post I threatened to split serialization out into its own distribution. I'm not sure how this would overlap with something like Data::Serializer, which is currently used by some of C-A-REST's serialization formats. Maybe it'd be simpler to just punt to Data::Serializer for all the serialization and deserialization, but even then I'd have to keep some class names around for backwards compatibility.
Thoughts?
Punt
Let Data::Serializer pick up everything you want that layer to do. File tickets or patches or bug the Cat list to do it with/for you. That space is where it belongs. Put in deprecation warnings for anything "backwards compatible" and phase it out in the next major release to edge the code closer to "clean" over time.
Your stuff rules, by the way. I have only used it in experiments and personal stuff so far but I intend to use it for my next serious OS project.
Re: Catalyst-Action-REST update
I use C::A::R heavily in my current project, so I would hate to see it breaking compatibility :-)
There seems something odd going on with this fully automatic deserialization at the server, especially if I send JSON content
(with the proper Content-Type). Currently I work around that with sending
....'Content-Type' => 'application/octet-stream',
Content => to_json (....)
and doing it manually at the server.
So, more control/debugging in this area would be great!
Otherwise the integration with Catalyst looks good to me.
\rho
Use Serialize for what you
Use Serialize for what you use it for now, and simply Serialization for what you call now SerializeFormat?
How about Data::Serializable?
Maybe you should look at my CPAN module, Data::Serializable. It's a Moose role that uses Data::Serializer functions to do the actual serialization, with options for overriding the actual implementation.
It's used in my Log::UDP::Client and Log::UDP::Server modules.
Add your comment