On Friday, September 20, 2013 2:55:33 PM UTC+2, Florian Apolloner wrote: > > > Btw could it be that you are mixing out Encoder and Serializer? >
No, I say Serializer when I mean... well, a serializer, as specified by SESSION_SERIALIZER. I say Encoder when I mean the Encoder class used by JSONSerializer. It could be the one built into the json module, or it could be a derived one, such as DjangoJSONEncoder here https://github.com/django/django/blob/1.6b4/django/core/serializers/json.py#L79 Personally I don't see any improvement in using an extended encoder -- in > the end it's just more work for us and people complaining why we don't > support their $magical class. In most if not all cases storing full objects > in the session is wrong; what we could have supported would be timestamps, > but those are storable as utc seconds easily enough… Why would the current > status be discouraging anyone? > Easily enough is still more complicated than current solution storing datetime objects, possibly with tzinfo. It's discouraging to the users because, after you find out what the problem is, it's easier to revert to PickleSerializer (with no security compromise, if you don't use SignedCookies) than to circumvent the extra difficulties of adapting one's local status data to JSON. And third party apps devs will have the choice whether to deal with the same difficulties (without breaking compatibility with already existing projects) or just advice users to switch to PickleSerializer. It's just one line in your settings.py and has no inconvenience. I can see what you mean about people complaining. But it would be mitigating the migration issues implied by switching to JSONSerializer. You are trading a few vocal complaints for a generalized struggle. [...] that's what I'd call impact; the current impact is __only__ on [...] > The examples you mentioned (forms, admin) were significant improvements themselves, with big benefits to Django users. Switching the default session serializer to JSONSerializer is providing no benefit to any user. It's addressing a security problem (which is already documented) that only a few users have (can you provide a big^H^H^H list of users who use signed cookies but can't add a SESSION_SERIALIZER setting next to their SESSION_COOKIE_HTTPONLY and SESSION_COOKIE_SECURE settings?). I don't want to lose focus on my proposal. It's either to change the default to PickleSerializer or to mitigate the JSONSerializer issue supporting these data types: - datetime, timedelta objects (supported by DjangoJSONEncoder) - decimal objects (supported by DjangoJSONEncoder) - arbitrary binary strings (b'\xe8') - Geometry objects This doesn't include Models or other objects which don't have any obvious serialization format. As much as I'd hate to see (de)serialization code in views, I wouldn't consider a third option: a mechanism to provide custom serialization for other object types. I see it's already been discarded. Davide -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
