Re: Customizable Serialization check-in

you've tackled various parts of it. All the best, Tom On Thursday, 23 August 2012 01:14:26 UTC+1, Piotr Grabowski wrote: > > Hi, > > Google Sumer of Code is almost ended. I was working on customizable > serialization. This project was a lot harder than I expected, and sadly &g

Re: Customizable Serialization check-in

Hi, Google Sumer of Code is almost ended. I was working on customizable serialization. This project was a lot harder than I expected, and sadly in my opinion I failed to do it right. I want to apologize for that and especially for my poor communication with this group and my mentor. I want

Re: Customizable Serialization check-in

Hi, In the past 3 weeks, my project has changed a lot. First of all I changed output of first phase of serialization. Previously it was python native datatypes. At some point I added dictionary with metadata to it. Metadata was used in second phase of serialization. Now after first phase I

Re: Customizable Serialization check-in

W dniu 11.07.2012 14:04, Russell Keith-Magee pisze: There is still problem with API and how to do some things but in my opinion it's going in right direction. Generally, I agree. I still have some concerns however; mostly around the things that you're putting onto the Meta class.

Re: Customizable Serialization check-in

On Wed, Jul 11, 2012 at 8:18 AM, Piotr Grabowski wrote: > Hi, > > It is time to midterm evaluation of my participation in gsoc so I want to > summarize in this check-in what I have done in last month. > https://gist.github.com/3085250 - here is something that can be >

Re: Customizable Serialization check-in

Hi, It is time to midterm evaluation of my participation in gsoc so I want to summarize in this check-in what I have done in last month. https://gist.github.com/3085250 - here is something that can be "documentation". I wrote some examples of ModelSerializer usage and how it should work.

Re: Customizable Serialization check-in

W dniu 26.06.2012 11:52, Tom Christie pisze: > It is the way I am doing deserialization - pass instance to subfields Seems fine. It's worth keeping in mind that there's two ways around of doing this. 1. Create an empty instance first, then populate it with the field values in turn. 2.

Re: Customizable Serialization check-in

> default deserialized_value don't returns anything. It sets the field value. Cool, that's exactly what I meant. > but declaring function only to say "do nothing" isn't good solution for me. Declaring a method to simply 'pass' seems fine to me if you want to override it to do nothing. > It

Re: Customizable Serialization check-in

W dniu 20.06.2012 13:50, Tom Christie pisze: >deserialized_value function with empty content Are you asking about how to be able to differentiate between a field that deserializes to `None`, and a field that doesn't deserialize a value at all? No :) I had this problem before and I managed to

Re: Customizable Serialization check-in

> if I put list in input I want list in output, not generator I wouldn't worry about that. The input and output should be *comparable*, but it doesn't mean they should be *identical*. A couple of cases for example: *) You should be able to pass both lists and generator expressions to a given

Re: Customizable Serialization check-in

Hi! This week I wrote simple serialization and deserialization for json format so it's possible now to encode objects from and to json: import django.core.serializers as s class Foo(object): def __init__(self): self.bar = [Bar(), Bar(), Bar()] self.x = "X" class

Re: Customizable Serialization check-in

Hi! This week I managed to write deserialization functions and tests. *Issues with deserialization* Working on deserialization give me a lot thoughts about previous concepts. I rewrite Field class so now Field can't be nested. Field can only have subfields if subfields are attributes: class

Re: Customizable Serialization check-in

Hi, Sorry for being late with weekly update. Due to some issues with Meta and my wrong understanding of metaclasses that Russell pointed I spend time on enhance my knowledge about this. I rewrote also some part of code that I have written week before. This week I will do what I was suppose

Re: Customizable Serialization check-in

W dniu 29.05.2012 02:28, Russell Keith-Magee pisze: Hi Piotr; Apologies for the delay in responding to your updated API. On Tue, May 22, 2012 at 6:59 AM, Piotr Grabowski wrote: I do some changes to my previous API: (https://gist.github.com/2597306<- change are

Re: Customizable Serialization check-in

Hi Piotr; Apologies for the delay in responding to your updated API. On Tue, May 22, 2012 at 6:59 AM, Piotr Grabowski wrote: > I do some changes to my previous API: (https://gist.github.com/2597306 <- > change are included) > >  * which fields of object are default

Re: Customizable Serialization check-in

On May 27, 7:37 pm, Piotr Grabowski wrote: > Hi, > > This week I started coding my project. It' available on branch > soc2012-serialization onhttps://github.com/grapo/django. > > I'm not very familiar with git so I'm not suer that I do it right: > * I forked django repo

Re: Customizable Serialization check-in

Hi, This week I started coding my project. It' available on branch soc2012-serialization on https://github.com/grapo/django. I'm not very familiar with git so I'm not suer that I do it right: * I forked django repo from github * clone it to my computer * create new branch soc2012 * work in

Re: Customizable Serialization check-in

I do some changes to my previous API: (https://gist.github.com/2597306 <- change are included) * which fields of object are default serialized. It's depend on include_default_field but opposite to Tom Christie solution it's default value is True so all fields (eventually specified in

Customizable serialization now passing Django's test suite.

I've been working away on django-serializers<https://github.com/tomchristie/django-serializers>lately, and I've now got a customizable serialization API that's backwards compatible with the existing serializers, and is passing Django's serializer tests. Exactly where I take this will

Re: Customizable Serialization check-in

Hi, During this week I was focused on my exams. Now I have more time for serialization project. Sadly API isn't finished yet. 21 May in gsoc calendar is time for start coding. Tomorrow I will send updates to API proposal and I will present idea of algorithm (maybe list of steps will be

Re: Customizable Serialization check-in

Hi, This week I think about internal API for Serializer. I want that developers can eventually use it for better customization of their solutions. Next week I must learn for my exams so I suppose I will not do much with serialization project. I will try to resolve some issues about my API

Re: Customizable Serialization check-in

W dniu 07.05.2012 20:13, Tom Christie pisze: Hey Piotr, Here's a few comments... You have 'fields' and 'exclude' option, but it feels like it's missing an 'include' option - How would you represent serializing all the fields on a model instance (without replicating them), and additionally

Re: Customizable Serialization check-in

W dniu 06.05.2012 10:45, Russell Keith-Magee pisze: - I'm not sure I follow how class_name would be used in practice. The act of deserialization is to take a block of data, and process it to populate an object. In the simplest case, you could provide an empty instance (or factory) that is

Re: Customizable Serialization check-in

Hey Piotr, Here's a few comments... You have 'fields' and 'exclude' option, but it feels like it's missing an 'include' option - How would you represent serializing all the fields on a model instance (without replicating them), and additionally including one other field? I see that you could

Re: Customizable Serialization check-in

On Sat, May 5, 2012 at 4:08 AM, Piotr Grabowski wrote: > Hi, > > During this week I have a lot of work so I didn't manage to present my > revised proposal in Monday like i said. Sorry. I have it now: > https://gist.github.com/2597306 Hi Piotr, At a high level, I think

Re: Customizable Serialization check-in

Hi, During this week I have a lot of work so I didn't manage to present my revised proposal in Monday like i said. Sorry. I have it now: https://gist.github.com/2597306 Next week I hope there will be some discussion about my proposal. I will also think how it should be done under the hood.

Re: More on Customizable Serialization

mchristie.com - Tom On Saturday, 28 April 2012 04:05:17 UTC+1, Russell Keith-Magee wrote: > > Hi Tom, > > On Friday, 27 April 2012 at 12:44 PM, Tom Christie wrote: > > Seeing another proposal for Customizable Serialization for the GSoC this > year > > prompted me to d

Re: More on Customizable Serialization

Hi Tom, On Friday, 27 April 2012 at 12:44 PM, Tom Christie wrote: > Seeing another proposal for Customizable Serialization for the GSoC this year > prompted me to dust off the bits of work I've done along similar lines. > I'd really like to see this get properly addressed in core and

Re: Customizable Serialization check-in

W dniu 27.04.2012 12:39, Tom Christie pisze: Hey Piotr, > I quickly skimmed the proposal and I noticed speed/performance wasn't mentioned. I believe performance is important in serialization and especially in deserialization. Right. Also worth considering is making sure the API can deal with

Re: Customizable Serialization check-in

m, Piotr Grabowski<grabowski...@gmail.com> wrote: > >> Hi! > >> > >> I'm Piotr Grabowski, student from University of Wroclaw, Poland > >> In this Google Summer of Code I will deal with problem of customizable > >> serialization in Django. >

Re: Customizable Serialization check-in

W dniu 27.04.2012 10:36, Anssi Kääriäinen pisze: On Apr 27, 11:14 am, Piotr Grabowski<grabowski...@gmail.com> wrote: Hi! I'm Piotr Grabowski, student from University of Wroclaw, Poland In this Google Summer of Code I will deal with problem of customizable serialization in Django. Y

Re: Customizable Serialization check-in

On Apr 27, 11:14 am, Piotr Grabowski <grabowski...@gmail.com> wrote: > Hi! > > I'm Piotr Grabowski, student from University of Wroclaw, Poland > In this Google Summer of Code I will  deal with problem of customizable > serialization in Django. > > You can

[GSoC] Customizable Serialization check-in

Hi! I'm Piotr Grabowski, student from University of Wroclaw, Poland In this Google Summer of Code I will deal with problem of customizable serialization in Django. You can find my proposal here https://gist.github.com/2319638 It's obviously not a finished idea, it's need to be simplified

More on Customizable Serialization

Seeing another proposal for Customizable Serialization for the GSoC this year prompted me to dust off the bits of work I've done along similar lines. I'd really like to see this get properly addressed in core and I thought it was about time I helped to make it happen. I've made a fairly

Re: [GSOC 2012] Customizable serialization

W dniu 03.04.2012 15:55, Tom Christie pisze: It breaks the problem down into two very well defined tasks. 1. Convert native datatypes to/from data streams. (eg. Tastypie's serializers , REST framework's

Re: [GSOC 2012] Customizable serialization

mentation first - it's getting the API design of the (de)serialization right that is the difficult part, not the implementation. Anyway, I hope those thoughts are helpful. I'd be very interested in seeing how this progresses... Cheers, Tom On Monday, 2 April 2012 17:20:27 UTC+1, Piotr

Re: [GSOC 2012] Customizable serialization

I am quite interested in this, as most of my coding work has been developing APIs that get consumed by non-web-browser software. Lately, I've taken the approach that a Form is the appropriate tool to use for (de)serialisation: it's already used extensively by the template rendering (which is

Re: [GSOC 2012] Customizable serialization

It's my second approach to customizable serialization. I did some research, find some REST serializers. I focus more on deserialization - it should be easy to provide data is round-trippable. I discard some unnecessary fields and try to improve functionality. GSOC 2012 Customizable

Re: [GSOC 2012] Customizable serialization

>    One of my principle was to let user define any possible structure. > Ex > > > > > Django > > > > > > 1. With Meta.structure you can do: > def name >    return Django > structure="a[b[c[name__field]]] > > 2. Without: > def a >    return BFieldSerializer > class BFieldSerializer >    

Re: [GSOC 2012] Customizable serialization

W dniu 20.03.2012 22:00, Łukasz Rekucki pisze: 1) The Meta.structure things looks like a non-starter to me. It's a DSL inside a DSL. I'm also not sure what it actually does - you already have all those @attribute decorators, why repeat their names in some string? One of my principle

Re: [GSOC 2012] Customizable serialization

Actually, thinking about it a bit more, it seems fk_level is bound to be a significant source of untested edge-case behavior. Every time the limit is reached, there will be an unexpectedly flat relationship that a naive recursive deserializer may choke on. I would be +1 on a fail-fast version of

Re: [GSOC 2012] Customizable serialization

I like the project and am +1 on Łukasz's points #1 and #3. Meta.fk_level looks very useful though. For example if models have parent/sibling relationships or otherwise relate to themselves and you can't guarantee the relationships are acyclic. Definitely a worthy project. -Alex Ogier -- You

Re: [GSOC 2012] Customizable serialization

On 20 March 2012 17:50, Piotr Grabowski wrote: > Hi, > > My name is Piotr Grabowski. I'm last year student at the Institute of > Computer Science University of Wrocław (Poland). I want to share with you > draft of my GSOC proposal. Hi, nice to meet you :) > >

[GSOC 2012] Customizable serialization

Hi, My name is Piotr Grabowski. I'm last year student at the Institute of Computer Science University of Wrocław (Poland). I want to share with you draft of my GSOC proposal. http://pastebin.com/ePRUj5HC PS. Sorry for my poor english :/ -- Piotr Grabowski -- You received this message

Customizable serialization (again and again)

Hi ! Again ! on this topic many times discussed : http://groups.google.com/group/django-developers/search?group=django-developers=serialization_g=Search+this+group https://code.djangoproject.com/wiki/SummerOfCode2011#Customizableserialization I came up with a framework that feels right to use

Re: Customizable serialization. (Finally?)

Cool, thanks, all good points. Slight haitus working on this right now whilst I try to get my head around the right way to try to bring it more into line with the Forms API, but hoping to pick it up again once I've marshaled my thoughts. Obviously I'll keep the list updated if I do make more

Re: Customizable serialization. (Finally?)

Hi! I put your code to good use in my project and have two minor suggestions: Make the signature of def get_related_serializer(self, key) like this: def get_related_serializer(self, key, obj): because the related serializer could also depend on obj (does for me). Secondly: the naming of

Re: Customizable serialization. (Finally?)

Yup. The current implementation (see the github repo) allows properties and methods that only take a 'self' argument to be serialized by adding the name to 'fields' or 'include'. If you need anything more involved then you'd write a custom method on the Serializer class. (or a custom

Re: Customizable serialization. (Finally?)

Looks really good, the current implementation for serialization is pretty limited, so this will be a breath of fresh air :) Using the proposed Serializations class, will it be possible to serialize properties of a model that is not fields, for example methods? On Jun 15, 12:18 pm, Tom

Re: Customizable serialization. (Finally?)

> A suggestion though, is to be able to declare serializers in a > similar fashion as models or forms. Actually that's a fair point, yup - the proposal could be made a little closer to the existing Forms and Models APIs. Something along these lines... class ModelPKField(SerializerField):

Re: Customizable serialization. (Finally?)

izer of field `some_char_field` class Meta: exclude = ('id', 'pk') That would things more consistent no !? On Jun 13, 4:14 pm, Tom Christie <christie@gmail.com> wrote: > Hi all, > >   Over the coding sprints at djangocon.eu I started working on a proposal

Customizable serialization. (Finally?)

Hi all, Over the coding sprints at djangocon.eu I started working on a proposal for customizable serialization. [1] I've talked over the API and implementation with Russ, and I think we're broadly happy with it all, so I'd like to open it up to wider discussion. What I have right now looks

Re: Customizable Serialization Proposal

> The purpose of this project is to define (and then implement) a DSL > for serialization. If a DSL is what you are looking for, then I withdraw my proposal. The idea of hosting yet another DSL inside Django project scares me a little. I'll just implement my idea as a separate project, I guess.

Re: Customizable Serialization Proposal

On Wed, Apr 6, 2011 at 11:31 AM, DaNmarner wrote: >> So - show me what it would look like. Show me how I, as a third party, >> would use your proposed syntax to define output that would match >> Django's existing serialization scheme. Yes, this serialization format >> will

Re: Customizable Serialization Proposal

> So - show me what it would look like. Show me how I, as a third party, > would use your proposed syntax to define output that would match > Django's existing serialization scheme. Yes, this serialization format > will exist as a built in default; but I should be able to reproduce > that format

Re: Customizable Serialization Proposal

On Wed, Apr 6, 2011 at 7:44 AM, DaNmarner wrote: >> 1) It's almost illegible. Between your mail client's munging of line >> wrapping, and the completely unreadable code samples, it's very >> difficult to tell if you have presented a good idea. > > Pardon the format. I

Re: Customizable Serialization Proposal

As a side note: I encountered the use case for customizing serialization last summer when building my own blog project (I wanted an app that could import/export my models from/to wordpress/blogger XML. The API I proposed largely emerged from my thought back then. I'm willing to commit efforts to

Re: Customizable Serialization Proposal

> 1) It's almost illegible. Between your mail client's munging of line > wrapping, and the completely unreadable code samples, it's very > difficult to tell if you have presented a good idea. Pardon the format. I actually auto-wrapped the text with vim and copy pasted at the first time. Realizing

Re: Customizable Serialization Proposal

On Sun, Apr 3, 2011 at 6:58 AM, DaNmarner wrote: > I've got some more crystalized details about my proposal. > > Here are the target result if this proposal is implementated: > > 1. User could configure serialization for each model. > > 2. In fact, user could configure the

Re: Customizable Serialization

On Thu, Mar 31, 2011 at 7:38 PM, Vivek Narayanan wrote: > Hi Russ, > > Thanks for the suggestions once again, I've thought of changing the > model for handling nested fields. > > Each model can have a no of serializers, and they can be plugged in to > other serializers > and in

Re: Customizable Serialization Proposal

After a few days' consideration, I've got some more crystalized details about my proposal. Here are the target result if this proposal is implementated: 1. User could configure serialization for each model. 2. In fact, user could configure the serialization details down to each field of each

Re: Customizable Serialization Proposal

I've got some more crystalized details about my proposal. Here are the target result if this proposal is implementated: 1. User could configure serialization for each model. 2. In fact, user could configure the serialization details down to each field of each model. That means: 3. The key

Re: Customizable Serialization

Hi Russ, Thanks for the suggestions once again, I've thought of changing the model for handling nested fields. Each model can have a no of serializers, and they can be plugged in to other serializers and in this way nested models can be handled instead of cycling through a tree of arbitrary

Re: [GSoC Proposal] Customizable Serialization

On Wed, Mar 30, 2011 at 4:08 PM, Russell Keith-Magee wrote: > On Fri, Mar 25, 2011 at 6:03 PM, Vivek Narayanan wrote: >>> When you start dealing with foreign keys and m2m, you have an >>> additional set of assumptions -- >>> >>>  * How far should I

Re: [GSoC Proposal] Customizable Serialization

On Fri, Mar 25, 2011 at 6:03 PM, Vivek Narayanan wrote: >> I think I see where you're going here. However, I'm not sure it >> captures the entire problem. >> >> Part of the problem with the existing serializers is that they don't >> account for the fact that there's actually

Re: [GSoC Proposal] Customizable Serialization

Hi Russ, Thanks for the long reply and all the suggestions. My comments are inline. > What if you need to support both? e.g., > > >     the bar value > > > It seems to me that you would be better served providing a way to > annotate each individual metadata value as (and I'm bikeshedding a >

Re: [GSoC Proposal] Customizable Serialization

On Thu, Mar 17, 2011 at 3:47 PM, Vivek Narayanan <m...@vivekn.co.cc> wrote: > Hi, > > This is my proposal for the customizable serialization idea: > > There are two formats - A formatted Google Docs version that's easy on > the eyes ( > https://docs.google.com/a/v

Re: [GSoC] Customizable Serialization Proposal

On Wed, Mar 23, 2011 at 1:28 PM, DaNmarner wrote: > First of all: my native language is not English, so I apologize for > any potential natural language error (or any error at all) below. > > After (briefly) reading through the current implementaion as well as > the "Issues

[GSoC] Customizable Serialization Proposal

First of all: my native language is not English, so I apologize for any potential natural language error (or any error at all) below. After (briefly) reading through the current implementaion as well as the "Issues to consider" section in the GSoC2011 page on wiki, my initial observation is that

Re: Customizable Serialization

> I also haven't seen any proposals or examples of how I'd use the API as > an end user - are people going to be able to register serialisers to > models (since they're apparently tied to specific models anyway)? There will be different types of serializers like JSONSerializer, YAMLSerializer,

Re: [GSoC Proposal] Customizable Serialization

On 17/03/11 07:47, Vivek Narayanan wrote: > Hi, > > This is my proposal for the customizable serialization idea: Hi Vivek - sorry about the long reply-wait on this! My initial thoughts are below. > The user can define methods beginning with “meta_” to add metadata > a

[GSoC Proposal] Customizable Serialization

Hi, This is my proposal for the customizable serialization idea: There are two formats - A formatted Google Docs version that's easy on the eyes ( https://docs.google.com/a/vivekn.co.cc/document/pub?id=1GMWW42sY8cLZ2XRtVEDA9BQzmsqnCNULzskDMwqSUXI ) and a plain text version that follows

Re: Customizable Serialization

On Mar 8, 3:14 pm, Tom Evans wrote: > Splitting down your project into small chunks will also demonstrate to > people reading your proposal that you understand the subject matter, > and they can have a high confidence of the project being delivered. Thanks, I didn't

Re: Customizable Serialization

On Mon, Mar 7, 2011 at 4:28 PM, Vivek Narayanan wrote: > ... > In the run up to May 23rd, I'll be familiarizing myself with the > codebase and community practices of Django, examining all the > integration points and looking at the best practices of serialization. > > Week 1:

Re: Customizable Serialization

On Mar 6, 11:54 am, Russell Keith-Magee wrote: > On Sun, Mar 6, 2011 at 2:41 PM, Vivek Narayanan wrote: > > @Sebastien: I got your point about using a dict as an intermediate > > structure and the use of recursion, and I looked at your > >

Re: Customizable Serialization

On Sun, Mar 6, 2011 at 2:41 PM, Vivek Narayanan wrote: > @Sebastien: I got your point about using a dict as an intermediate > structure and the use of recursion, and I looked at your > implementation which is somewhat similar to what I have in mind. > > Well, here is a list of

Re: Customizable Serialization

@Sebastien: I got your point about using a dict as an intermediate structure and the use of recursion, and I looked at your implementation which is somewhat similar to what I have in mind. Well, here is a list of deliverables for the project: • Investigate existing structure of the serializer,

Re: Customizable Serialization

Ok ... I have to admit I was not very clear. Here is what I meant, illustrated with some code examples : http://readthedocs.org/docs/django-serializers-draft/en/latest/index.html These are my "dream" django-serializers ! On Mar 1, 10:20 am, Vivek Narayanan wrote: >

Re: Customizable Serialization

@Sebastien, Thank you for your suggestions, that's exactly what I had considered. As I've mentioned earlier, I would like to start with providing basic XML, JSON, YAML and text serializers, that would be built on the existing base structure with a few modifications, as building blocks. But before

Re: Customizable Serialization

Hi I just stumbled across this discussion ... even though I have always been very interested about contributing to Django, I never took the step yet ! But this is actually a topic that interests me very much (even though for the moment it is Vivek's). For several projects I am working on (a lot

Re: Customizable Serialization

On Thu, Feb 24, 2011 at 10:24 PM, Vivek Narayanan wrote: > Hi, > > I am Vivek Narayanan, an undergrad student at IIT, Varanasi in India > and am interested in participating in this year's SoC Hi Vivek, and thanks for your interest in the GSoC! > Problem > >

Customizable Serialization

Hi, I am Vivek Narayanan, an undergrad student at IIT, Varanasi in India and am interested in participating in this year's SoC Problem Django provides a serialization framework that is very useful for loading and saving fixtures, but not very flexible if one wants to provide an API

Re: GSoC: Customizable Serialization

On Mon, Mar 29, 2010 at 10:00 PM, gombiuda JHL <gombi...@gmail.com> wrote: > Hi all. My name is Gombiuda Jiang. I want to apply the `Customizable > serialization` project. Here is my proposal. Thanks for your reading and > commenting. > As far as I can understand the project,

GSoC: Customizable Serialization

Hi all. My name is Gombiuda Jiang. And firstly I have to apologize for my mistake of sending a wrong version of the proposal. I want to apply the `Customizable serialization` project. Here is my proposal. Thanks for your reading and commenting. As far as I can understand the project, its aim

GSoC: Customizable Serialization

Hi all. My name is Gombiuda Jiang. I want to apply the `Customizable serialization` project. Here is my proposal. Thanks for your reading and commenting. As far as I can understand the project, its aim is to make serialization can be used out of fixture loading. For example, once we can customize

Re: Customizable Serialization Idea -GSoC

t 1:26 PM, Jesus Mager <fon...@gmail.com> wrote: >> Hi all! >> >> My name is Jesus Mager, and I'm student at the National Autonomous >> University of Mexico.I am interested in  in taking part of Google >> Summer of Code for the diango project. >> The Custom

Re: Customizable Serialization Idea -GSoC

On Tue, Feb 23, 2010 at 1:26 PM, Jesus Mager <fon...@gmail.com> wrote: > Hi all! > > My name is Jesus Mager, and I'm student at the National Autonomous > University of Mexico.I am interested in  in taking part of Google > Summer of Code for the diango project. > The Cu

Re: Customizable Serialization Idea -GSoC

On Tue, Feb 23, 2010 at 12:26 AM, Jesus Mager <fon...@gmail.com> wrote: > Hi all! > > My name is Jesus Mager, and I'm student at the National Autonomous > University of Mexico.I am interested in  in taking part of Google > Summer of Code for the diango project. > The Cu

Customizable Serialization Idea -GSoC

Hi all! My name is Jesus Mager, and I'm student at the National Autonomous University of Mexico.I am interested in in taking part of Google Summer of Code for the diango project. The Customizable Serialization sound a good idea. Django have actually a really fine system, so we can handle xml