El ago 7, 2013 3:51 a.m., "Richard Schwarting" <aquarichy gmail com> escribió:AFAIR we have commented before. I've not changed that. But agree with your comments.
>
> Hi Daniel.
>
> Thanks again for the work. So, I haven't compiled and run your code in the serialization branch, but after reading it, I have some questions, to help me better understand what your goal is.
>
> *** DomNode.vala
> - is there any reason that you're defaulting _str to "DomNode" for to_string ()?
> - in theory, it gets built anew each time. (In fact, I'm not sure whether we need the _str field anymore.)
>
> *** Element.valaAgain it was discussed before. I need to set text inside a node without remove serialized objects (in my branch they are serialized as child nodes if they are properties).
> - any particular reason you're changing from set_content to
> add_content when we're setting the content of an Element?
>May be GXml must add a method to set text as Value in a node without remove child nodes. May be a "value" property, I'm using very-long properties name in order to avoid conflicts with serializable GObject ones.
> *** NodeList.valaI agree. Just changed because I was searching for a bug fix. If you change that I'll run a test to see this is not a problem when deserializing objects (in my branch I need to iterate over all nodes and pass to deserialize object's method)
> - NodeListIterator.advance () should not need to explicitly call
> .is_empty () because the calling code, GenericNodeListIterator, does
> that itself. NodeListIterator.advance has protected visibility, so
> nothing outside will be calling it either.
>
> *** Serializable.vala
>
> The interface for Serializable was modelled off of ebassi's
> serializable interface for JSON. The names of the interface methods
> and their signatures are intended to resemble those in GObject and
> GObjectClass.First all I *want* to keep unchanged your method. Just want to allow implementors/users to select the one better for their application.
I would like to have a top Serializable interface and derived implementators classes one per method.
>
> I notice that you've explicitly changed the names of some methods, and seemed to move some class methods of Serialization into Serializable methods. Any particular reason why?This is a good discussion. I moved away because conflicts with use case, one is the GObjectClass and the other is Serializable, the second, l think must have a different approach because in my branch you can select if a particular property is avoided when serializing, while in the first returns all of them. I think method's names are more clear with this vision.
>
> I'm going to read through the logic now and see what motivates all the new methods.
>
> Cheerio,
> Richard Schwarting
>
>
> On Tue, Aug 6, 2013 at 5:31 PM, Richard Schwarting <aquarichy gmail com> wrote:
>>
>> I'll probably have to get back to you with tomorrow on comments on your branch. Sorry.
>>
>>
>> On Tue, Aug 6, 2013 at 4:58 PM, Richard Schwarting <aquarichy gmail com> wrote:
>>>
>>> I finally pushed the change to serialization to gsoc2013 that fixes it. The main change (breaking API) is that instead of gxml_serialization_serialize_object () returning a GXmlNode (which was the document_element of a document) it now returns a GXmlDocument (and its document_element is what you used to get). Consequently, gxml_serialization_deserialize_object () now takes a GXmlDocument, which incidentally cleans up the API usage slightly (you don't have to read a document and then pass doc.document_element; instead just pass the doc!).
>>>
>>> I've requested a mailing list:
>>> https://bugzilla.gnome.org/show_bug.cgi?id=705571
>>>
>>> Let me know about the invalid UTF-8 strings. I think they were related to the case where the memory was already freed before the serialize_object () method returned the GXmlNode.
>>>
>>> I'll look into parallel installation. My current plan for releasing is:
>>> 0.3.2: all the non-API changes pushed here, so people who are using 0.3.x can keep doing it with the fixes.
>>> 0.4: most of the API breaking things, of which there are a few more coming (all classes are going to reflect their corresponding names from the W3 DOM spec; it's silly that I let them vary to begin with).
>>>
>>> Regarding IRC, right now I lurk in #gtk+ and #vala, so if you just want to talk to me, you can find me there. We can create an impromptu #gxml one for now if you like, or we can formally do it.
>>>
>>> I'm going to review and comment on your serialization finally.
>>>
>>> Sorry for the delay, GUADEC is busy, and so is my Masters, so I've had a hard time being as responsive as I should be.
>>>
>>> Cheerio,
>>> Richard Schwarting
>>>
>>>
>>>
>>> On Mon, Aug 5, 2013 at 4:14 AM, Daniel Espinosa <esodan gmail com> wrote:
>>>>
>>>> Great!
>>>>
>>>> I'm not too much on irc. But I could if you consider benefit.
>>>>
>>>> What is the channel we can join?
>>>>
>>>> Really thanks for your advise. For now I think gxml serializable is almost ready, but really considering to use TextReader/Writer for serialization because memory use, or add an interface to implement it, I've created a branch locally for this witch I can share i you want, but at the end, are you planning to release shortly a 0.4, if so my plans on TextReader/Writer must wait.
>>>>
>>>> I'm planning to provide gxml parallel features with C# Serializer, I have a project on sourceforge called OpenSCLConfigurator using that tech but I want to rewrite it using Vala.
>>>>
>>>> El ago 4, 2013 8:45 p.m., "Richard Schwarting" <aquarichy gmail com> escribió:
>>>>
>>>>> Just to keep you up to date, hacking resumes tomorrow (the last day of talks at GUADEC ended today). My primary goals are this, reviewing Adam Ples' patch in Bugzilla, and preparing releases.
>>>>>
>>>>> Are you on IRC much?
>>>>>
>>>>>
>>>>> On Wed, Jul 31, 2013 at 2:16 PM, Daniel Espinosa <esodan gmail com> wrote:
>>>>>>
>>>>>> Great! Thanks.
>>>>>>
>>>>>> I'm waiting for it in order to merge again and add my own test cases to serializable and fix Serialization to handle two ways: the actual one in 0.3 and the new one in up coming 0.4
>>>>>>
>>>>>> By the way, I think we need to add 0.4 sufix to .pc, Gir, subdirectories and others, in GXml in order to allow parallel installation with 0.3 series.
>>>>>>
>>>>>> One example is Gda.
>>>>>>
>>>>>> https://git.gnome.org/browse/libgda/tree/libgda/Makefile.am
>>>>>>
>>>>>> As far I can see you have all infrastructure to make the change.
>>>>>>
>>>>>> An for last, are there a gxml mailing list? To make this discussion public?
>>>>>>
>>>>>> El jul 31, 2013 12:29 a.m., "Richard Schwarting" <aquarichy gmail com> escribió:
>>>>>>
>>>>>>> Oh, I can fix that. I'll do that once I arrive at GUADEC. Thanks for the heads up.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 30, 2013 at 6:59 PM, Daniel Espinosa <esodan gmail com> wrote:
>>>>>>>>
>>>>>>>> Just to know if I need to file a bug.
>>>>>>>>
>>>>>>>> gsoc2013 branch, witch I've synced with my serialize branch, fails to run make check command.
>>>>>>>>
>>>>>>>> My problem is at /gxml/serialization/xml_serialize
>>>>>>>>
>>>>>>>> fruit_xml.to_string () returns invalid UTF8 strings, but it is not consistent, some rare cases just get in an infinity loop, others messages like;
>>>>>>>>
>>>>>>>> output error : string is not in UTF-8
>>>>>>>>
>>>>>>>> Some times empty strings.
>>>>>>>>
>>>>>>>> Are your make check command works for you?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Trabajar, la mejor arma para tu superación
>>>>>>>> "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>