newbuildutility.txt

we could have a server listening to requests and always on (one server for all projects) Without the GHC API it shouldn't take much memory. 
Calls that use the GHC API should be run in a separate process (one process for each open file???) 

what is the purpose of the synchronized temp folder?
	- save in there files not saved by the editor so that preprocessing et al can be done (run GHC on new file)
	- having all files there mean we get an exact replica except of the changed file
	- BUT we do not need it for builds!

synchronize
	create/synchronize sub folder (.dist-toolname) and ensure all files that have changed in base folder are present in folder
	read cabal config
		- all src fields
			- all exposed/other modules
		- all Main-Is
		- all data files
		- Setup.hs?
	-> requires configure to have a flattened description!
	can take a file name and only work on that
	can take a reset flag that ensure all files are the same (remove generated files)

configure
	configure in proper folder
	cabal API call
		maybe a executable call + parse result is better (warnings and such will just be written to output, so we need to parse it anyway)
	with additional flags (enable-tests)
	parse errors and warnings

build
	build in proper folder
	require configure
	cabal executable/API call?
	parse errors and warnings

getAST
	maybe several files at once in one session for performance
	requires build
	use GHC API
		like in scion now
		no link
		use cabal flags
		target wanted module (avoid unwanted side effects with errors)
		use copied file in temp folder (means we should be able to use generated files, etc)
	store AST to disk
		qualified names
		source locations
	GHC AST issues:
		- complexity
		- parsed AST (not typechecked) can caus panics (placeholder types)
		- we do not need the typed AST for a lot of operations
	or only use haskell-src-exts?? And rely on scion-browser to find the qualified names? What about preprocessed names, etc...	
		- probably easier to use
		- parseFileWithExts -> use extensions from all possible cabal components?
			- determine cabal components from cabal files (file name -> module)

tokenTypes
	- current scion code, lexing synchronized file
	- need to transform file to remove preprocessing
	- reuse a scion server?

occurences: use existing code
	- or for performance, code in Eclipse (do not call executable)
		beware the differences between token types and tokens! We do not get the token contents with just toekn types
		

thingAtPoint
	requires getAST from GHC -> typechecked
	load AST from disk and use current scion code
		-> qualified name should allow us to find the location

outline
	requires getAST
	load AST from disk and use current scion code
	- use new code if using haskell-src-exts
	- done by client using JSON representation of AST
	- may as well code a default implementation
		- tested with rest of API
		- much smaller size of JSON passed back
		- can deal with haskell-src-exts data instead of JSON...

namesInScope?
	GHC API names in scope -> requires typechecked module
		- provide correct module with only imports -> always correct, only to get names?
			- we could add a loop: generate module with only imports, if error then get line and remove imports
	Use haskell-src-exts to get top level declarations 
		- use outline
	Then we could just ignore GHC and use outline for declarations and scion-browser for other imports?
		- but scion-browser doesn't know about our own project declarations 

tokens (preceding,etc): still needed? 

find available imports
	lists all available symbols from modules (except modules after it in the dependency chain)
	lists all available symbols from other packages
	???
	scion-browser gives us that

writeFileContents
	take file name and string contents
	write into temp folder
	-> build
	*** Of course in Eclipse we can just write the file ourselves (expose getTargetPath?) so we don't have to pass the file contents to executable
			Just write the file in target, then call build/outline/tokens (even in parallel, by the way)
	

test
	parse Cabal results...

	

architecture:
synchronize, configure, build, tokens, occurences, outline: single invocation of process: buildwrapper <command> <cabalfile> <filepath> <options>
thingAtPoint, namesInScope: start a buildwrapper server  (IF PERF IS NOT GOOD ENOUGH VIA SINGLE INVOCATION) 
		buildwrapper start <cabalfile>
			load <filepath>
			getNamesInScope
			getThingAtPoint <line> <col>
	- one server per opened editor file
	- reload module when synchronized
	- stop and restart server when cabal file changes	
	- what about dependent modules?? can we find when they're modified and reload?
	
when an editor is saved:
	- save contents to temp file in distbuildwrapper folder or call synchronize <filepath>
	- call build False
	- reload corresponding buildwrapper server
	- call a reload on dependent buildwrapper servers
		the "load" method of the buildwrapper server returns modules we depend on? -> "when one of them changes, reload me!"