search

krakenjs / spud

A content store parser, reading a java .properties-like format
Other
14 stars 9 forks source link

Drop support for serializers other than `.properties` #14

Closed aredridel closed 9 years ago

aredridel commented 10 years ago

JSON is mostly debugging output.

V4 can be used with spud@0.0.3 if needed, and converted to a more modern format that way.

Other formats have features we can't represent, don't need, or don't want, and are theoretical anyway.

diegone commented 10 years ago

I'm not sure I understand the rationale here. Since spud is part of the overall kraken machinery and it's the only place that supports pluggable alternative formats, how would one go about implementing their own formats which may be existing and/or preferred?

If the idea is that the spud dependency will be generalized and other spud-compatible implementations can be plugged in, then I'm all for it. If we're saying going forward this is the only format kraken supports it'd be like saying that we only want to support dust going forward and we want to prevent other template systems to be used.

rragan commented 10 years ago

Kraken is open source so who knows what other folks out there might want to convert to .properties via plugging their format into spud. What is the rationale for dropping support?

aredridel commented 10 years ago

If there's a strong case for it, then absolutely. However, spud would be much, much simpler if it didn't support -- and focus on -- being format-agnostic. Right now in our own use, we only use one format. We're talking about extending the API to export metadata, too, which will increase the complexity of other serializers too -- or they'll only handle a subset of what's expected of them.

The only public package that we didn't write that depends on spud is https://www.npmjs.org/package/grunt-cellarise-makara

totherik commented 10 years ago

I suggested we investigate this. Once we add features as described by issue #13 we no longer have a document format, but at the very least a DSL (if not a proper AST) against which each serializer must conform. We already have this situation with the properties format which, to my knowledge doesn't serialize to PayPal's XML-based format (due to support for subscript and indexed notation). Once we add these additional features, spud becomes much less general-purpose. If we want spud to just be an AST transformer, then we should pull ALL rules into separate serializer.

diegone commented 10 years ago

I believe PayPal's XML-based format supports current issue #13 format (metadata, nesting and sequences are supported) and beyond (it has some sort of message format definition).

totherik commented 10 years ago

Yep, but AFAIK it supports the features but I don't believe any existing serializers support converting even the existing features correctly.

diegone commented 10 years ago

That sounds like bug and it's probably because nobody is using the xml serializer.

totherik commented 10 years ago

Yep, and as I intended to express originally, without XML we're left with properties and JSON. Since JSON is natively supported and the intermediate format for ALL serializers it seemed silly maintain a plugin system around just properties files.

diegone commented 10 years ago

I think people may be interested in the XML deserializer since that's where the majority of content already is and since properties file are not at feature-parity yet, so migration is not an option yet.

aredridel commented 10 years ago

What features are needed for migration?

kkleidal commented 10 years ago

Excuse my naivety, but I'm gonna pull the intern card and ask a stupid question: why migrate from XML when XML already supports metadata and the majority of content (according to @diegone) is already in XML?

diegone commented 10 years ago

AFAIK legacy XML supports content overrides/adaptations within the same file, translate, localization notes, markup and variable in message format, control data. I may be missing some other features like specialization, but I'm not sure about it.

aredridel commented 10 years ago

Two things:

Developers hate XML.

Is the expense of those features worth it? I suspect the answer is 'no'.

kkleidal commented 10 years ago

It was worth it for Google devs when they made android. It just feels like we're spending a lot of time reinventing the wheel. I don't know; that's just my two cents.

aredridel commented 10 years ago

Yeah. And as evidence for this, the Android APIs are unpleasant and unwieldy, and so far, people are largely turning out much inferior applications on Android than IOS. Certainly not much of a datum, but I certainly think they made some missteps there.

diegone commented 10 years ago

I'm ok treating the Developers hate XML blanket statement as a system constraint. I also think that JSON is much more intuitive than XML for a lot of use cases (e.g. configs). But if developers hate XML so much, why are we using DUST instead of JADE for example? If "we hate XML" is a constraint it should be avoided everywhere as much as possible. And because DUST is 90% HTML, and properties files are nothing but pieces of dust templates, guess what 90% of properties files are made of...

Going back on topic, I think some developers may hate properties file as well so one way or another we should keep the ability to change resource file format.

aredridel commented 10 years ago

Dust is a textual language, not XML. Nor is HTML XML.

We're also looking at becoming independent of Dust, since there's interest in other technologies, both templating and templateless.

aredridel commented 10 years ago

Is there another format we should be considering?

diegone commented 10 years ago

Here's an idea I had a few years ago, it was fun to spec out last night. Ready to be crushed! ;)

https://github.com/diegone/jsup

aredridel commented 9 years ago

Fixed in v2.0.0