1. Typelibs are "development" time resources not runtime.
2. In Eclipse development nearly every resource you ever use for development time is local to your environment.
3. VJET is a tool and typelibs can be thought of as metadata for the VJET plugin/tool.
4. Eclipse projects are a very standard way for Eclipse to manage dependencies and expose resources (source, libs, assets, etc...).
5. Typelibs can have dependencies and so on, so Eclipse projects make this support natural and are well integrated to the Eclipse tooling platform and other plugins.
6. Typelibs are themselves VJET types. This makes them natural as "source" artifacts in the VJET development environment. If we think about Java then a VJET type lib is both source and binary.
7. Developers can create their own typelibs as well as their own _javascript_ artifacts and use a standard Eclipse development mechanisms/practices to integrate them.
Some alternatives/ideas:
1. I do see the merit for some alternative referencing semantic as you mentioned. If we look at something like XML and for XML support for external resolvers (think XML schemas). People could post their typelibs as a internet resource and have their Eclipse refer to those resources. Of course coming up with composition, dependency, resolution, and validation mechanisms for external resources would probably be a bit of work.
2. I don't know enough about Eclipse internals but there is a full "Resource Model" abstract that may allow for a resource to be a proxy to some remote entity.
3. Eclipse uses plugins/bundles so its possible to leverage this infrastructure for some support.
Best,
MrP
