Azaezel Posted May 16, 2015 Posted May 16, 2015 The difference with JSON and XML serialisers is they serialise to exactly what it says on the tin, not to several other file formats. So basically, you're advocating for a more generalized term, like serialSource, or something along those lines to denote the subsystem isn't an explicit format-parser? Quote
buckmaster Posted May 16, 2015 Author Posted May 16, 2015 Maybe not that generic, but yes. Something like TAOS (torque app object serialisation) or TASL (torque app serialisation layer), but with less terrible acronyms. Also note that I'm not saying this is critical, just that it seems like a good idea. I know it involves renaming a bunch of stuff, which is annoying. While I'm making ideological ideas, I'd also rename .taml to just .xml because that's what it is, AFAICT. Though that one's less significant. Quote
JeffR Posted May 16, 2015 Posted May 16, 2015 Maybe not that generic, but yes. Something like TAOS (torque app object serialisation) or TASL (torque app serialisation layer), but with less terrible acronyms. Also note that I'm not saying this is critical, just that it seems like a good idea. I know it involves renaming a bunch of stuff, which is annoying. While I'm making ideological ideas, I'd also rename .taml to just .xml because that's what it is, AFAICT. Though that one's less significant. I think i'd be OK with the system being called TASL, though I think it's somewhat low priority an issue.That said, negatory on renaming taml format to xml. Remember, taml can be stored as xml, json or binary. May be worth calling it something other than taml, but it being changed to xml as an extension is pigeonholing it. Quote
buckmaster Posted May 18, 2015 Author Posted May 18, 2015 Remember, taml can be stored as xml, json or binary.See, that's exactly the sort of thing this silly naming has made a problem of. TAML can serialise Torque objects to an XML file, a JSON file, or a binary file. TAML, by default, associates a different file extension with each of those formats. Though it looks like the programmer can overwrite this, so you could store JSON or binary in a .taml file if you wanted to.Which, now I think about it, might be what you want if you want to serialise your assets as binary when you publish, for file size reasons. You don't want to have to rename your file paths when you switch format. Unless you can load a TAML file without specifying the extension, in which case it's a moot point.What I'm saying is, currently, .taml usually means XML syntax. If you have a .taml file with JSON syntax, it will either be suffixed .json, or you have to write special logic to load it properly. So to avoid confusion between TAML the serialisation system and TAML the file format, which is actually just XML, I think writing to .xml would be preferable. That may be just me though :p. Quote
JeffR Posted May 18, 2015 Posted May 18, 2015 Remember, taml can be stored as xml, json or binary.Though it looks like the programmer can overwrite this, so you could store JSON or binary in a .taml file if you wanted to. See, I'd just embrace this behavior. I honestly completely forgot about the other file extensions because you don't need to use them if you don't want.So embracing taml as the standard extension(or whatever we switch it to) would make sense to me. Quote
buckmaster Posted May 19, 2015 Author Posted May 19, 2015 Same file extension for different encodings? Sounds like a recipe for pain :(. Or do you mean getting rid of the non-XML encodings? Quote
rlranft Posted May 19, 2015 Posted May 19, 2015 Naw, if the system detects the encoding on load then who cares? The only real pain involved is when Billy Coder opens that .taml in a text editor and can't read it because he forgot he saved everything in binary mode.I mean, do what you like with it but this really sounds like much ado about nothing. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.