It seems ridiculous for me to talk as if I know what I am doing, but I figure
you guys will be forgiving...
Its a mad place for me to start learning, reorganising the whole code base as
an exercise. From what I have seen so far (which is not a lot)...
I prefer to be able to define an explicit load list, rather than a search path.
- Search paths can be the source of hard to find bugs. I spent an hour
or two yesterday trying to debug an apache conf, when all the time an old file
was being picked up in the search path.
I was quite surprised to find that the bootstrap.js was not data driven.
If the bootstrap.js is part of the "corest, kernelist" part of lively, I would
expect to see the list of modules would be better pulled out into the
start.xhtml somehow. The list could be moved into the Config somewhere. ves
sorting out some of decisions that boostrap.js is making i.e. isCanvas. I would
even consider putting up two hard coded lists, i.e. CanvasModules and
NormalModules.
I am experimenting with moving the load list call into start.xhtml
Instinctively I am thinking that I would like the load list to be recursive,
that modules can specify a list of modules. In which case the top level config
would call in the "core" top modules and the "users" top modules. If this was
the case, a "canvas" module could only load in submodules if canvas is not
present. However, nothing is going to be faster and clearer than an explicit
list, so that would be my preference.
regards
Keith
> Hi, Fabian --
>
> sounds nice, just like Java classpath, but what about overriding modules?
> And... the most important of all, how do
> we figure out if a module can be loaded in this or that part on the client
> side? Should we check before every module
> load if the module is available under rootA, rootB or rootC? We could use
> node.js to do it on the server for us...
> or another idea:
> Don't use additional roots but "link" in other path into our root. We could
> explicitly register "webwerstatt/users" for the
> users prefix... this would also allow us to map non file system based modules
> from the codeDB into our normal module schema without having to user special
> chars as codeDB1 did....
>
> Best,
> Jens
_______________________________________________
lively-kernel mailing list
[email protected]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
