{
	"id": "171817",
	"key": "TIMOB-26142",
	"fields": {
		"issuetype": {
			"id": "7",
			"description": "gh.issue.story.desc",
			"name": "Story",
			"subtask": false
		},
		"project": {
			"id": "10153",
			"key": "TIMOB",
			"name": "Titanium SDK/CLI",
			"projectCategory": {
				"id": "10100",
				"description": "Titanium and related SDKs used in application development",
				"name": "Client"
			}
		},
		"fixVersions": [],
		"resolution": {
			"id": "2",
			"description": "The problem described is an issue which will never be fixed.",
			"name": "Won't Fix"
		},
		"resolutiondate": "2018-06-26T15:54:21.000+0000",
		"created": "2018-06-20T12:54:26.000+0000",
		"priority": {
			"name": "High",
			"id": "2"
		},
		"labels": [],
		"versions": [],
		"issuelinks": [
			{
				"id": "56629",
				"type": {
					"id": "10001",
					"name": "Cloners",
					"inward": "is cloned into",
					"outward": "is cloned from"
				},
				"inwardIssue": {
					"id": "171818",
					"key": "TIMOB-26143",
					"fields": {
						"summary": "Windows: Deprecate Ti.XML in favor of standalone module",
						"status": {
							"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
							"name": "Closed",
							"id": "6",
							"statusCategory": {
								"id": 3,
								"key": "done",
								"colorName": "green",
								"name": "Done"
							}
						},
						"priority": {
							"name": "High",
							"id": "2"
						},
						"issuetype": {
							"id": "2",
							"description": "A new feature of the product, which has yet to be developed.",
							"name": "New Feature",
							"subtask": false
						}
					}
				}
			}
		],
		"assignee": {
			"name": "hknoechel",
			"key": "hansknoechel",
			"displayName": "Hans Knöchel",
			"active": true,
			"timeZone": "Europe/Berlin"
		},
		"updated": "2018-08-02T22:20:08.000+0000",
		"status": {
			"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
			"name": "Closed",
			"id": "6",
			"statusCategory": {
				"id": 3,
				"key": "done",
				"colorName": "green",
				"name": "Done"
			}
		},
		"components": [
			{
				"id": "10202",
				"name": "Android",
				"description": "Android Platform"
			},
			{
				"id": "10206",
				"name": "iOS",
				"description": "iOS Platform"
			}
		],
		"description": "Our Ti.XML namespace has been around a while now. Nowadays, most of the common-used API's are JSON-based and based on the usage reports, there are not many devs left using this API inside the core. But still, it is still included, with it's 37 files. Removing it would mean a huge compile time bump, so it should be deprecated and moved to a standalone module, like we recently did with Ti.Yahoo.",
		"attachment": [],
		"flagged": false,
		"summary": "TiAPI: Deprecate Ti.XML in favor of standalone module",
		"creator": {
			"name": "hknoechel",
			"key": "hansknoechel",
			"displayName": "Hans Knöchel",
			"active": true,
			"timeZone": "Europe/Berlin"
		},
		"subtasks": [],
		"reporter": {
			"name": "hknoechel",
			"key": "hansknoechel",
			"displayName": "Hans Knöchel",
			"active": true,
			"timeZone": "Europe/Berlin"
		},
		"environment": null,
		"closedSprints": [
			{
				"id": 1058,
				"state": "closed",
				"name": "2018 Sprint 16 SDK",
				"startDate": "2018-07-29T22:26:06.486Z",
				"endDate": "2018-08-12T22:26:00.000Z",
				"completeDate": "2018-08-13T17:38:16.757Z",
				"originBoardId": 114
			}
		],
		"comment": {
			"comments": [
				{
					"id": "438639",
					"author": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"body": "I strongly believe we must retain XML support in the SDK proper. This is a industry standard data exchange format. The spec is stable. Ti.XML is not like Ti.Yahoo where it is a 3rd party service.\r\n\r\nI get moving it to a native Titanium module, but this is a huge mistake. They would need to activate the module in the tiapp.xml and require the module to use it. This is a poor developer experience.\r\n\r\nEither leave Ti.XML alone or move it into a pre-compiled framework/library that the Titanium build will detect the use of Ti.XML and alter the project to link to it during compile/link.",
					"updateAuthor": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"created": "2018-06-22T16:29:16.000+0000",
					"updated": "2018-06-22T16:29:16.000+0000"
				},
				{
					"id": "438712",
					"author": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"body": "[~cbarber] Party agree. Yes, it is stable and standard, but it should not be packaged with every application. What I would like to do is to move it to a module and link it to our xcode project of Ti.XML.* is used. Therefore, we could a) save compile time if used by having a framework and b) save compile time when not using it by ripping out the framework link.\r\n\r\nThis would require a build change as well, which should be small enough.",
					"updateAuthor": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"created": "2018-06-26T13:26:41.000+0000",
					"updated": "2018-06-26T13:27:10.000+0000"
				},
				{
					"id": "438713",
					"author": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"body": "[~hknoechel] When you say module, do you mean a Titanium module or a framework/library?",
					"updateAuthor": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"created": "2018-06-26T13:28:46.000+0000",
					"updated": "2018-06-26T13:28:46.000+0000"
				},
				{
					"id": "438714",
					"author": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"body": "Titanium module, static library. Once our [swift support|https://github.com/appcelerator/titanium_mobile/pull/9983] is merged, our native modules will be frameworks, so I mis-spelled it :-).",
					"updateAuthor": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"created": "2018-06-26T13:30:01.000+0000",
					"updated": "2018-06-26T13:30:01.000+0000"
				},
				{
					"id": "438717",
					"author": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"body": "You cannot do a Titanium module. If you do, then you will need to inject {{Ti.XML = require('ti.xml');}}. This is not elegant. It maybe acceptable in the future to force users to require() the XML module, but I believe we can and should make this automatic.\r\n\r\nAgain, I propose you move the XML APIs into a native framework/library and if the build detects Ti.XML being used, then the build links to the framework/library. No need to require() anything. Robust, doesn't break anything.\r\n\r\nLet's be clear here, iOS is the problem. iOS is the only platform that does NOT pre-build it's native code during scons. This is the root of the build time problem. We've had ticket TIMOB-12186 open for 5-1/2 years to fix this and nobody has stepped up to the plate. I brought this up at the last eng week. iOS needs to get on the bandwagon and compile as much of its code during scons and have the result packaged with the SDK. This would make building the Titanium app even faster than just ripping Ti.XML out. Please, please, please, please do some house cleaning and fix the Xcode project so that scons builds the iOS platform code during scons. Add a new Xcode project if you need to. Organize the {{classes}} directory and clean up the iOS platform.",
					"updateAuthor": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"created": "2018-06-26T13:50:05.000+0000",
					"updated": "2018-06-26T13:50:05.000+0000"
				},
				{
					"id": "438718",
					"author": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"body": "Why would we need to require it? It's just a namespace that is linked via the static library. So if defined (= {{USE_TI_XML}}), the namespace can be made available in our source. And thats btw exactly what's described in the other ticket, although it does not make sense to compile the whole SDK inside a library, since it a) makes the app size too large and b) will cause save app rejections because symbols (= API's) are compiled into the app although not used.",
					"updateAuthor": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"created": "2018-06-26T13:53:43.000+0000",
					"updated": "2018-06-26T13:55:28.000+0000"
				},
				{
					"id": "438719",
					"author": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"body": "I didn't know Titanium modules had access to the Titanium namespace. Not sure if that's brilliant or an issue.",
					"updateAuthor": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"created": "2018-06-26T13:56:15.000+0000",
					"updated": "2018-06-26T13:56:15.000+0000"
				},
				{
					"id": "438720",
					"author": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"body": "I don't see how pre-building the iOS platform would make it any larger. As for the symbols, that's why you ship a debug and a release build of the framework/library. This is standard practice.",
					"updateAuthor": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"created": "2018-06-26T13:57:44.000+0000",
					"updated": "2018-06-26T13:57:44.000+0000"
				},
				{
					"id": "438721",
					"author": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"body": "It's the main reason we wrapped all larger API's in our precompile macros ({{USE_TI_*}}). Some critical examples that other frameworks need to worry about because of this:\r\n- Camera, Music, Video API's -> App rejected if compiled into the app but not used\r\n- Contacts -> Same\r\n- Background Services / Silent-Pushes -> Same\r\n\r\nWe had some of these issues in the past as well, but having the wrapping now solves it quite elegant for us and people love it. BUT: The above Swift-PR moves out our CORE to an own framework, so the whole JSCore handling will be precompiled - and works pretty nicely already. It saves us around 90 of ~310 classes already, which is pretty cool as well.",
					"updateAuthor": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"created": "2018-06-26T14:02:47.000+0000",
					"updated": "2018-06-26T14:02:47.000+0000"
				},
				{
					"id": "438722",
					"author": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"body": "I didn't say you need to pre-build the entire iOS platform code into a single framework/library. Android and Windows both have the various Titanium namespaces in separate libraries that the build system will include as needed into the final build. No need for macros because the build system takes care of it.",
					"updateAuthor": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"created": "2018-06-26T14:06:21.000+0000",
					"updated": "2018-06-26T14:06:21.000+0000"
				},
				{
					"id": "438723",
					"author": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"body": "Thats also not possible. Ti.Media.showCamera & Ti.Media.audioSessionCategory. Same class, different API's. If not wrapped -> rejected. This cannot be done by the build. And Android still compiles all modules into the app from what I think. It's rather for the package based Android ecosystem.",
					"updateAuthor": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"created": "2018-06-26T14:09:25.000+0000",
					"updated": "2018-06-26T14:09:25.000+0000"
				},
				{
					"id": "438724",
					"author": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"body": "It is possible because the build system can detect the difference between {{showCamera}} and {{audioSessionCategory}}. Android build does something similar to auto select permissions: https://github.com/appcelerator/titanium_mobile/blob/master/android/cli/commands/_build.js#L3625.\r\n\r\nAndroid certainly does NOT compile all modules into the app. It only compiles in what is used: https://github.com/appcelerator/titanium_mobile/blob/master/android/cli/commands/_build.js#L3027-L3047.",
					"updateAuthor": {
						"name": "cbarber",
						"key": "cbarber",
						"displayName": "Chris Barber",
						"active": true,
						"timeZone": "America/Chicago"
					},
					"created": "2018-06-26T14:13:18.000+0000",
					"updated": "2018-06-26T14:14:34.000+0000"
				},
				{
					"id": "439754",
					"author": {
						"name": "emerriman",
						"key": "emerriman",
						"displayName": "Eric Merriman ",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Closing old \"Won't fix\" tickets. If you disagree, please reopen.",
					"updateAuthor": {
						"name": "emerriman",
						"key": "emerriman",
						"displayName": "Eric Merriman ",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2018-08-02T22:20:08.000+0000",
					"updated": "2018-08-02T22:20:08.000+0000"
				}
			],
			"maxResults": 19,
			"total": 19,
			"startAt": 0
		}
	}
}