I made a bunch of huge simplifications that resulted in this feature basically being hardly new code:
fand is just a core sys thing, not its own pod (nuke src/fand on your local drive)
there are no new classes to support fand
services are just plain old sys::Threads
My basic train of thought is that threads are already "named services" designed be looked up by name and then exchange messages with. So I don't think it makes sense to create a special Service class, when really that is what Thread already is. We might end up creating a couple special lifecycle APIs, but those should just be rolled into Thread anyways.
Take that a step further and it is logical to assume that something like WispService or UserService is a subclass of Thread. This means that services are const and immutable. Any other strategy is ugly because it requires at least two classes to model a service - the immutable thread and the mutable configuration. So I'm sticking to things being clean and a Service is const - eventually we'll have to decide how changing the config of a service works - does it require a restart of the entire process or maybe just a restart of that thread (probably the latter). But for now it will require a process restart.
So the bootstrap is pretty simple: look in for all the fog files in the /appHome/services directory, decode them as Threads, they are mounted using their filename, once everything is mounted, all the threads are started.
The fallout of this design means that services are identified by a Str name and resolved via Thread.find.
I'll keep a working demo checked in - to run it: fand demo
brian Sat 22 Dec 2007
Basic fand functionality is ready to go!
I made a bunch of huge simplifications that resulted in this feature basically being hardly new code:
My basic train of thought is that threads are already "named services" designed be looked up by name and then exchange messages with. So I don't think it makes sense to create a special Service class, when really that is what Thread already is. We might end up creating a couple special lifecycle APIs, but those should just be rolled into Thread anyways.
Take that a step further and it is logical to assume that something like WispService or UserService is a subclass of Thread. This means that services are const and immutable. Any other strategy is ugly because it requires at least two classes to model a service - the immutable thread and the mutable configuration. So I'm sticking to things being clean and a Service is const - eventually we'll have to decide how changing the config of a service works - does it require a restart of the entire process or maybe just a restart of that thread (probably the latter). But for now it will require a process restart.
So the bootstrap is pretty simple: look in for all the fog files in the /appHome/services directory, decode them as Threads, they are mounted using their filename, once everything is mounted, all the threads are started.
The fallout of this design means that services are identified by a Str name and resolved via Thread.find.
I'll keep a working demo checked in - to run it: fand demo