agreed. since the audience of the MicroKernel API is pretty small
programmer-friendliness has admittedly not been a top priority ;)
I think programmer-friendliness should have a higher priority then.
Where did this priorities come from btw?
Programmer unfriendly api's lead to programmers designing ad-hoc
convenience wrappers which lead to fragmentation and broken windows.
This is already now apparent from the jr3 prototype code base! Which is
pretty alarming to me.
OTOH portability, remotability, stateless nature and compactness
have been. having those goals in mind, JSON is IMO a perfect fit.
Again, where did these goals come from? What are the rationals?
While I think having a stateless api is a good think, I think we should
not let this preclude other features and functionality. For example
having the commit method to contain all the transient changes in a
single json string will limit the size of transient modifications.
We could as well allow transient changes to be written to the micro
kernel and then committed later on:
changes.add(mk.writeTransient("+/foo/bar, {}"))
changes.add(mk.writeTransient("+/foo2/bar2, {}"))
...
mk.commit(changes)
IMO this is as stateless as the other approach.
Michael
cheers
stefan
BR,
Jukka Zitting
