I would like to get some feedbaack on loaders. As you can see (only from svn repository, it is not packaged yet), I have started creating extension point for loaders. The idea is, roughly, this:
Extension point defines loader and file extensions it can handle. Plugins that extend this extension point can declare one or more loaders that can handle different file types.
This is all fairly simple and conceptually clean, but I need some feedback on how would loaders be used. I can think of only two use cases:
1. Replace whole scene with the loaded tree.
2. Append loaded tree to existing group.
Any other use cases?
Please feel free to join discussion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why do we need different use cases? IMHO a loading facility just has to return a tree. The application is responsible for appending it to a scene or completely replace the scene.
Kind regards, Sebastian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In that case loaders extension point (and accompanying harness) will serve merely to easily iterate over available loaders, where loaders would be represented by extensions. It is totally up to the application what will it do with it - that is fine by me. I wasn't sure if this was enough.
A loader should define a filename extension (or more) and a factory via extension point.
The loading facility can now find a suitable loader, create an instance with the factory, invoke the loader and return a subgraph.
The programmer just has do pass a filename (or a URI or whatever), and the rest is done by the loading facility.
Another possible way could be streams. In that case, the programmer gets a suitable loader (by the filename extension, why not) and invokes it.
But the details are up to you :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Loaders extension point and plugin offers a mechanism for
1) Enumerating all available loaders (without actually instantiating the loaders) and listing extensions they can handle,
2) Instantiating given loader (factory). The application would have to decide which loader is to be used, or maybe there could be a convenience method which takes file name and tries to deduce which loader from file's extension.
And that's all. Application would have to use the instantiated loader exactly the same as it would in a non-eclipse environment (retrieve Scene object and pick what it needs, and then do what it wants with it).
Yes, this is simplistic, but that's exactly what I wanted. I couldn't decide on the level of abstraction that eclipse-loader interface should provide. But this is good - makes thing clean. It can always be "complified" later :-)
Is that what you were suggesting?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I would like to get some feedbaack on loaders. As you can see (only from svn repository, it is not packaged yet), I have started creating extension point for loaders. The idea is, roughly, this:
Extension point defines loader and file extensions it can handle. Plugins that extend this extension point can declare one or more loaders that can handle different file types.
This is all fairly simple and conceptually clean, but I need some feedback on how would loaders be used. I can think of only two use cases:
1. Replace whole scene with the loaded tree.
2. Append loaded tree to existing group.
Any other use cases?
Please feel free to join discussion.
Hi,
sounds like a good approach.
Why do we need different use cases? IMHO a loading facility just has to return a tree. The application is responsible for appending it to a scene or completely replace the scene.
Kind regards, Sebastian
Good.
In that case loaders extension point (and accompanying harness) will serve merely to easily iterate over available loaders, where loaders would be represented by extensions. It is totally up to the application what will it do with it - that is fine by me. I wasn't sure if this was enough.
There are a few techincal issues remaining:
1. What should be the interface: for now, extension point provides the application a way to query for loader's capabilities and to invoke loader. However, after loader has done the work should this interface simply make com.sun.j3d.loaders.Loader interface available to the application, or should this interface be abstracted a little? Any suggestions on how would application use it? (See what I started here: http://java3d-eclipse.svn.sourceforge.net/viewvc/java3d-eclipse/org.java3declipse/trunk/org.java3declipse.loaders/src/org/java3declipse/loaders/Loaders.java?revision=105&view=markup currently, it only contains "supported file extensions" API)
2. related to 1), should extension point provide all capabilities envisioned by Loader interface (I started something along those lines, see http://java3d-eclipse.svn.sourceforge.net/viewvc/java3d-eclipse/org.java3declipse/trunk/org.java3declipse.loaders/schema/java3dLoader.exsd?revision=105&view=markup , element name="java3dLoaderFlags")?
3. Technical issue: do we want to provide OS-dependent file extensions, or do we assume they will work on all OS-es?
Thanks
A loader should define a filename extension (or more) and a factory via extension point.
The loading facility can now find a suitable loader, create an instance with the factory, invoke the loader and return a subgraph.
The programmer just has do pass a filename (or a URI or whatever), and the rest is done by the loading facility.
Another possible way could be streams. In that case, the programmer gets a suitable loader (by the filename extension, why not) and invokes it.
But the details are up to you :)
Ok, just to conclude:
Loaders extension point and plugin offers a mechanism for
1) Enumerating all available loaders (without actually instantiating the loaders) and listing extensions they can handle,
2) Instantiating given loader (factory). The application would have to decide which loader is to be used, or maybe there could be a convenience method which takes file name and tries to deduce which loader from file's extension.
And that's all. Application would have to use the instantiated loader exactly the same as it would in a non-eclipse environment (retrieve Scene object and pick what it needs, and then do what it wants with it).
Yes, this is simplistic, but that's exactly what I wanted. I couldn't decide on the level of abstraction that eclipse-loader interface should provide. But this is good - makes thing clean. It can always be "complified" later :-)
Is that what you were suggesting?