El abr 2, 2014 9:33 a.m., "Richard Schwarting" <richard schwarting ca> escribió:
>
> Serializable.serialize():
> What's better?
>
> 1. GXmlNode serialize (GXmlNode node)
> - you're already using it
> - the implementation has access to the underlying owner_document (should specify in documentation that a user should use that, and not naively create a new GXmlDocument, to create any new nodes)
> - downside is that the caller has to identify a node in an advance to serialize it into (though they could probably just use doc.document_element if they're lazy)
>
That is correct. Documentation must state that the user must pass a Document or a Node. The implementation must handle both.
> 2. GXmlNode serialize (GXmlDocument doc)
> - Jgs is already using it
> - advantage over passing a node is that the caller doesn't have to prepare a Node to store it in, in advance, they can just pass a document and have the serialization implementation automagically append it to the document root (or wherever implemented methods decide to)
> - I like this one best
>
Because a Document is a Node, is better to simplify the API using just one handle both.
Keep in mind that a GObject could be serialized to any Node (a Document an Element or an Attr) is a matter of the implementation to serialize or not to the Node type. Support more than one could be possible, just let implementator to decide.
> 3. GXmlNode serialize ()
> - can't unless we drastically change the memory model (since this way, we wouldn't have a direct reference to the Document and it would be freed and our returned GXmlNode would be invalid
Even this not clear to me. Let the user to keep its own Document reference and decide when to free it.
Returning serialized Node you can add stuff like name spaces or any other, but is very important to allow override default implementation like Xom does.
> 4. GXmlDocument serialize ()
> - not so hot, since we wouldn't have a direct reference to the GXmlNode for the XML we just serialised into, we'd have to search the document for it.
> - benefit is that the caller wouldn't need to create/manage a GXmlDocument before serializing
>
>
I think is better return a Node because you always know the Node you have serialize to in order to custom serialization (like overriding the default, calling the default one inside your implementation and use the returned Node to add your own stuff to it)
>
>
> On Wed, Apr 2, 2014 at 11:24 AM, Richard Schwarting <richard schwarting ca> wrote:
>>
>> My idea is reflected in the new branch "serialization_isolation" where I'm basically moving serialization implementations into their own submodules/directories. Just for the general idea. One issue with SerializableJson is that it needed to 'implement' features it doesn't want. It wants to be dead simple and as automatic as possible. So instead I'm going to mostly adapt the original Serialization to go under its own submodule, jgs, with a bare Serializable interface under just gxml/ (as reflected in the previous e-mail).
>>
>> I'm going to ask some questions about the interface shortly. If you disagree with my suggestion to structure your serialization work under its own subdirectory, the interface questions will still be applicable to even if it's kept in the main one.
>>
>>
>>
>> On Wed, Apr 2, 2014 at 10:20 AM, Richard Schwarting <richard schwarting ca> wrote:
>>>
>>> Would you actually be amenable to including serialization under a nested namespace, in its own directory, as a submodule?
>>>
>>> That helps alleviate the issue of its size a bit. GXml was originally just a wrapper around libxml2 that provided a DOM API. With Serialization not being its main purpose, your Serialization code in your branch is about ~1/3 the entire code base. If it's its own submodule, then I don't think it matters how big it gets.
>>>
>>> I used the word unnecessary above, because just to serialize a GObject into XML on disk and back, a lot of the features are unnecessary, but I shouldn't use that word, as you obviously have use cases that are valid, that you're making use of. You mentioned how your serialization API could be used to actually save application data in existing formats, I believe. (Like AppData.) Whenever I look at it, I've foolishly been trying to minimise the amount of "feature creep", to avoid including a bunch of code that ultimately gets rarely used. If it's a submodule, I don't mind it having a life of its own. (E.g. make and commit whatever changes to the submodule you want!)
>>>
>>> When I said complicated, it's in part because the original goal in adding Serialization was to keep it Simple and Automatic. You've recently added some wonderful, useful code for serializing different Gee structures. My hope was rather instead of handling class-specific code to handle such things, to work towards a way to better automatically handle them. (Some of them would require new functionality in either gir or vala to be able to access private fields that weren't properties, which is ugh and a long way off.)
>>>
>>> So, if you wanted to use XML Object Model as the name of your submodule (or whatever you like), we could have directories like:
>>> gxml/
>>> gxml/xom/
>>>
>>> And a namespace like
>>> GXml.Xom
>>>
>>> We could let the common serializable interface be defined at something like
>>> gxml/Serializable.vala
>>> gxml/jgs/JgsSerializable.vala /* for json-glib-style serialization */
>>> gxml/xom/XomSerializable.vala
>>>
>>> If you'd like this, I'm fine with trusting you to also push changes to gxml/xom/ whenever you like. If you need to make changes to gxml/* stuff outside of gxml/xom/, I'd also be fine with a short review window (1 week?) after which if I don't even respond, you can just push things anyway.
>>>
>>> You've written a lot more code than I have over the past 8 months especially. Largely I've been unavailable due to school and work and budo, but it's stupid of me to prevent you from advancing GXml somewhere useful. You're also a good programmer, so you should be free to commit changes at this point, I think. I mostly want to keep the core of GXml small, keeping most implementation details in libxml2 for now.
>>>
>>> Does having Xom as a submodule completely under your control sound good? If so, if you can make that change and merge it, it'll make reviewing individual pieces a lot easier.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 1, 2014 at 7:02 PM, Richard Schwarting <richard schwarting ca> wrote:
>>>>
>>>> I'm still working on the last review you requested. Basically I want all the serialization merged, but not exactly as is. It's just gotten really big and hard to get done in a single sitting.
>>>>
>>>>
>>>> On Tue, Apr 1, 2014 at 6:49 PM, Daniel Espinosa <esodan gmail com> wrote:
>>>>>
>>>>> Thanks for your response.
>>>>>
>>>>> El abr 1, 2014 2:35 p.m., "Richard Schwarting" <richard schwarting ca> escribió:
>>>>>
>>>>>
>>>>> >
>>>>> > No.
>>>>> >
>>>>> > It is large, complicated, and makes unnecessary changes.
>>>>>
>>>>> I think we need more than just say that.
>>>>>
>>>>> > It also consumes all my free time that I have to work on GXml trying to restart reviews on
>>>>>
>>>>> I haven't seen you working on GXml in months.
>>>>>
>>>>> > it since earlier ones never had their concerns addressed.b
>>>>> >
>>>>> >
>>>>>
>>>>> Again please!!! Send to this list your concerns, even the ones at early commits I can explain you what and why each.
>>>>>
>>>>> I've been waiting for a while with no comment.
>>>>>
>>>>> All my work always have been public at early stages.
>>>>>
>>>>> I think we can't hold my work indefinitely.
>>>>>
>>>>> > On Tue, Apr 1, 2014 at 3:00 PM, Daniel Espinosa <esodan gmail com> wrote:
>>>>> >>
>>>>> >> I've found serialization branch ready to merge.
>>>>> >>
>>>>> >> * Fixed and stabilized Serialization framework
>>>>> >> * Fixed and running win32/win64 compilation
>>>>> >>
>>>>> >> Task TODO:
>>>>> >>
>>>>> >> * Fix Unit Test in order to get no error/warning messages
>>>>> >> * Clean up Serialization class in order to support default and user defined
>>>>> >> serialization method for GObjects
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> 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)
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> gxml-list mailing list
>>>>> >> gxml-list gnome org
>>>>> >> https://mail.gnome.org/mailman/listinfo/gxml-list
>>>>> >>
>>>>> >
>>>>
>>>>
>>>
>>
>