raw notes

- research memory usage of UrlService

- finish up url service
	- urlService utility needs a rewrite
	- e.g. if i change / to /home in my yml file and i call urlService.urlFor('post', data), i would receive /welcome and not /home/welcome
		- i think post.url must die on the model layer (!) -> this is nothing the model has knowledge of -> different layer (routing)
		- but we still need to ensure that we return the current post url to the admin interface
		- need to dig into that part a little deeper
		- same for tag: the url utility uses static route keywords, but instead we need to use the taxonmoies/resources of the yml file (!)
		- i think some of the routing keywords must die???
	- which data is required to fetch for the urlservice?
		- id, slug, type is currently remembered
		- memory currently goes up because we fetch all attributes, but we only keep a minimal set in process (memory goes up and goes down after ~2mins)
			- we can reduce the memory by using "columns: id, slug"
		- i think the url service should not cache the whole data set right now
		- i think the urlservice could use a DataCache, which can be disabled/enabled -> but this is a different feature
		- for now the url service just knows which urls are available in the service
	- if the first request comes in, we have to ensure that the url service did finish it's url caching
	- > need to be able to apply filters to existing JSON objects, to see if they match. Therefore reworking and extending GQL is a must.
		- this happens because the urlsrvc fetches all the data on bootstrap
		- now it has to figure out which post belongs to which collection
		- based on FILTERS (which actually run against the db)
		- the question now is: should we rewrite GQL to see if objects match a filter
		- OR should we fetch the data already based on the route patterns 
			- that means the component, who instantiates collections etc, will trigger the urlsrvc to cache a set of routes
			- we also need to keep in mind, that we might need a similar logic for apps ? e.g. /subscribe
			- e.g. fetch filter=x for /podcast/:slug/
			- if we run them sequentially, the urlsrvc is able to keep unique urls for each post
			- ????????
		- what we then need to do is, if we register /nature/:slug as express route, we have to ensure the UrlSrvc has the requested url
			- alternatively, we don't register ANY routes in express and use a * and ensure the url is known in the UrlSrvc
	- the event listeners in the url service won't work anymore
		- needs a little rewrite
			- because currently it just calls toUrl, which does not return the correct url

- sitemaps rewrite ??????
	- if the urlsrvc does not cache any data, except of the urls, why should the sitemap generator request the urlsrvc?
	- sitemaps generator needs more information e.g. modified date, images
	- 

- write the channel controller
	- handles rss (if not disabled)
	- handles pagination
	- fetches the data

- write the basic controller
	
- write collection class
	- this.controller = ChannelController
- write resource/taxonomy class
	- this.controller = ChannelController
- write routes class
	- this.controller = BasicController
- base class of these three types will be able to resolve resource paths e.g. page.home

- yml file reader + parser
	- default yml file lives in the Ghost core tree
	- if you provide a custom yml file, we prefer this file
	- we fallback to the default yml file if we can't read the custom yml file