Lets do it.
Do you agree if I move all serialization stuff in a subdirectory, using an another subdirectory for each jgs and xom?
If so I can start moving things. That's mean we need Serialization common interface will life in serializable and xom interface at xom directory. That's means too that your all code must be recovered from history, no problem.
About Seriization interface, as pointed by you, must call serialize() if the object is a serializable object if not I think we need to add a way (or GObject property to set a method to be used when de/serialize().
About all your early emails, I consider them as an agreed, then I'll use them as reference when working on GXml.
Regarding the json-glib style implementation, if we're going to both implement the same Interface, I want to shrink the interface to just require methods and stuff that both will actually use. Hence the version in the serialization_isolation branch.
Part of the goal of json-glib serialization is to minimise the choices a developer has to make. I don't mind having a common interface that gets extended by Xom, but I don't want a common interface that has too much non-essential stuff.
The string/gvalue stuff already had a class method in Serialization...I appreciate all the added features and options your Xom implementation provides, but I really want the bare serialization interface to minimise work for the developer and be as automatic as possible. A small interface doesn't necessarily restrict future implementations, but a large interface puts a lot of choice and more work on a developer.
Hence I'd still like it if Xom was under gxml.xom (and json-glib style will be gxml.jgs).On Wed, Apr 2, 2014 at 5:07 PM, Daniel Espinosa <esodan gmail com> wrote:
All these Serializable interface's features allows great flexibility for future implementations.e) Allows to de/serialize Text objects inside Element Nodes, as you want a GObject's property to be serialized as a Text inside an Element.d) Allows to use user defined node names by using property's nick (just using property name you get canonical names 'property_name' is 'property-name', using nick you can use names like 'PropertyName', 'propertyName' or any other you need for better description at XML representation).c) Handle unknown GXml.Node (allowing to have free formed XML files, parse in memory and write back to XML, and to avoid data lost).b) String to/from GValue standard transformationsa) Decide witch properties to serialize/deserializeAllowing Serializable as is, allows any other implementations in future to get minimal functionality as for:Even allowing Json implementing Serializable as is, allows Serializable Gee implementions to serialize any GObject as Json transparently.Json implementation, just don't use most of Serialization interface, but still works as expected initially, is just simple than ObjecModel implementation and still allows any to override its defaults and/or re-use them.I really think we can keep the way it is.I'll start to merge soon. Thanks.I'll start to move my work in a different directory, but for now I'll keep GXml namespace until you review my thoughts in early emails.
2014-04-02 13:02 GMT-06:00 Richard Schwarting <richard schwarting ca>:
Let me know what you think of the API questions I also sent. I'd like the json-glib-style serialization (intends to be simple and automatic, not rich and featureful like yours :) to share the same core API methods, so I'll change them as necessary based on the questions from earlier.If you end up wanting to keep it as a submodule (just within GXml, but inside its own directory), I'm also fine with that.In the future, I'll be more responsive to changes to core GXml that you might need. If you want to make a change and I don't reply with a review within a week, then feel free to commit it to merge it as you see fit.c) your serialization implementation is quite large :D, over half the size of the rest of the library. :Db) have your own release schedulea) complete autonomy over the direction of it, and won't be blocked by me being busy or overwhelmedI agree. You may merge what you need to now. I've looked at the code enough that I don't think there are any serious issues (besides some documentation errors :D), and I've been using it in my own projects this past week (I have two for school that use GXml!) that I haven't seen problems.Having it as a separate library makes sense since you'll have
On Wed, Apr 2, 2014 at 2:10 PM, Daniel Espinosa <esodan gmail com> wrote:
Thanks for your comments.
Lets work in that way. I'll work on serializable branch to create a library depending on GXml. ALL my work will be moved and merged later.
I would like to break master freeze for a long time now, please accept to merge now and monitor my commits to create Xom library.
Even I don't know if Xom will be a nested or independent name space.
For your suggestion to have two Serializable implementations under different namespace, means that may is better to fork my work in a different library depending on GXml 0.4.
By merging now most modifications to get parallel installation and Windows build will remain; just you'll see commits moving out Xom from GXml.
Do you agree?
El abr 2, 2014 8:20 a.m., "Richard Schwarting" <richard schwarting ca> escribió:
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.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.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.gxml/xom/XomSerializable.valagxml/jgs/JgsSerializable.vala /* for json-glib-style serialization */gxml/Serializable.valaWe could let the common serializable interface be defined at something likeAnd a namespace likegxml/So, if you wanted to use XML Object Model as the name of your submodule (or whatever you like), we could have directories like: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.)Would you actually be amenable to including serialization under a nested namespace, in its own directory, as a submodule?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!)
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.
gxml/xom/
GXml.Xom
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
>>
>
--
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)