Drop XML-support in 2.0?

[eriksundin]

Big milestone coming up, 2.0, room for big changes. A bold thing to bring up as I know a lot of work has been put into it, but wanted to lift this question any way. Let me know your thoughts.

Myself coming from a Spring framework background grasp and accept the XML-configuration approach for Typhoon. It's a good option to have, even though personally I've never used it. How ever, to a majority of our target users in the iOS/OSX community this option of configuration might be more confusing than providing a feeling of 'freedom of choice'. It's been up for discussion before to tone down the xml-approach, which we've done.

Key here is to present and package Typhoon as something easy to pick up to reach as many people as possible, but of course be very feature rich and extensible for the advanced user. But is the XML-option needed? Having just the block style assembly option will be straight-forward to users. Forced usage, Apple style! Focus is and has been on the block style assembly for a long time and if there is not a demand for the XML option I'd suggest we stop supporting it. Or moving it to another repo?

Again, bold statement. Don't shoot me. 🙏

[jasperblues]

I've thought about this too, and was certainly tempted. I wouldn't mind personally if we dropped it as I really prefer (and have encouraged others to use) the block-style assembly, which has the following benefits:

• Powerful code completion
• Powerful refactoring
• No magic strings
• Run-time arguments.

However there are a few users who prefer XML:

• @jrjarrett does (or did)
• @NielsKoole does (or did)

I think as long as we point out the benefits of the block-style its not doing any harm to have XML there. (Its only one extra class to translate the XML into native)

Also, it creates a proving ground for future styles of assembly, by promoting the architecture of having a native internal format, and translating to that format, which was the original premise of both Spring and Typhoon (www.typhoonframework.org#faq)

There are some charms to the XML approach and if its working for some folks, I don't think we should force them out.

Still, if we did a survey and found that users had already transitioned (or are prepared to) away, I'd be happy to proceed.

[jasperblues]

The other plan with XML was I was going to use it as the basis of a GUI tool. But I don't know if we'll ever get time for that realistically. . . also am finding code to be much more fluent and flexible.

[AlexDenisov]

XML support sounds like a Cargo cult.
This approach was copied from the old Java world.
But, in the Java world you mostly have big enterprise applications, which should work in different environments (different OS, testing, stable, so on), so that makes more sense to have small XML config, than recompile system for each platform.

Does someone really have such systems in iOS/OS X development? I don't believe in that.

P.S. Sorry if my thoughts sound rude, I don't want to insult anyone.

[jasperblues]

@AlexDenisov Even if you need run-time configurable properties, Typhoon still supports this with the block-style, using TyphoonConfig, loading from a file in the application bundle (allows testers to tweak eg a game settings without recompile) or elsewhere.

[jasperblues]

My vote 👍 unless someone talks us out of it.

[jasperblues]

If anyone needs, we can do a migration script to convert from XML to block style. . . . (as a penance, I could even make that migration script out of an XSLT stylesheet ;) )

[alexgarbarev]

My vote: keep XML available as cocoapods module, disabled by default. That way will force newcomers to use assembly style and provides options to keep using XML (who really need it)..

[drodriguez]

I’m with Alex, either as a Cocoapods module, or as a different project. If you want to use Typhoon with XML you use “typhoon” and “typhoon-xml”. The problem with either one of these approaches is that maintenance cost is still there.

I have never used Typhoon XML and I don’t plan to, so I will not cry for it if you drop it.

[jasperblues]

Hmmmm. The maintenance cost is still there as well as the cost to move it out. And I can see more chance that it will get broken and not fixed. On top of that its a more complicated build-server setup to maintain (trigger builds of the module after builds of Typhoon Core).

There's definitely merit in:

• Moving the documentation, API and project to a separate module.
• Having it around, because though while not so popular it is useful in certain situations.

. . however, if we invest effort there, its time we could've invested elsewhere (such as Typhoon AOP, which will be very useful). . . I would love to keep it as a separate module, but wonder if its worth the effort.

Realistically it would probably take several days of work to move it out. . . those days can be hard to come by. Therefore, more inclined towards 'kill or keep'

[bynelus]

Thanks for mentioning. I'm not longer using XML style anymore, so to me the XML approach can be taken out!

[jasperblues]

Thanks @NielsKoole, good to know.

[jrjarrett]

I've not had much of a chance to do iOS development lately (day job as a Java programmer keeping me pretty busy) so if no one else is using the XML based approach, don't keep it in on my account.

[alexgarbarev]

After few hours of refactoring and improvements I believe that we have to drop XML support in 2.0. Keep it as legacy project, and stop maintaining..
It is painful to support both configuration APIs

[eriksundin]

Ok. It seems consensus is to remove it. And I see there is now a label "Do It!" on the issue. ;-)
I will take this one on as I brought it up.

[eriksundin]

Ready for review in remove-xml-config branch.