WWJ features wish list

[patmurris]

Features i'd like to see in the stable SDK :

Compatibility with actual WW installed base:

• Cache directory/files and 'packs' - would save TBs of bandwidth
• Support for WW XML layer definitions and add-ons
• Data sources - data formats and servers used by WW

Core features

• A standard plug-in architecture - so that all applications using the SDK can benefit from them in a standard way
• Light and shading - this must be done in the core i think
• Support for different projections for the source images
• Support for irregularly shaped bodies - asteroids and small moons
• Offline mode - no internet access
• Auto update capabilities - not sure this can be done for an embedded 'component'

Documentation

• A road map
• Some 'real' documentation with architecture diagrams, code samples and 'general philosophy' description

[patmurris]

More items

Core features

• Fog support - a valuable depth/3D visual cue IMO
• Colorized terrain elevation capabilities - this has to do with terrain mesh texture mapping. It is unclear whether this can be achieved from 'outside' the component.

Note : some of those items may not need to be coded in the WWJ SDK and may fall in the scope of the host application or plug-ins. But this is still very unclear at this time.

[MichaelEGR]

Core additions / changes

Greets.. Here are some of my thoughts and directions I'd like to pursue sooner than later. I would like to contribute these potential core changes to WWJava. I'd definitely not want to fork anything, so open collaboration is desired when it comes to the core.

Here is my list:
1. I would like to structure the gov.nasa.worldwind package into a more discrete layout instead of the soupish nature that it currently is in presently.

2. I would like to make the rendering core OpenGL binding agnostic, so that LWJGL and JOGL can easily be supported.

3. I would like to have a separate source root for the demo application that depends on core.

4. I would like to move the awt package to a separate source root - perhaps a generic apps oriented one. Ideally I'd like the core renderer to not have to own it's own GL context and display component and make that explicit.

5. I'm certainly keen on supporting OSGi to provide a component framework for WWJava.

-------------------------------------------

Some details required for these changes:
1. Just create various packages that split up the core into finer grained logical areas.

2. It would be rather nice to make the core system capable of using either binding or perhaps in the future a 3rd GL or even DirectX binding if one emerges. This requires a little more separation across the core. There are two approaches. The 1st is make a proxy for the bindings, but the best way seems to be separate rendering peers per binding. These rendering peers should be located in separate source roots, but share packages with the core classes. Going the render peer direction requires #1 as it would require protected methods and member fields for some data and having fine grained packages would be nice in this regard.

3. This is quite easy. IE separate all non-core functionality into a separate source root that depends on the core.

4. The reason to do this is to make the rendering core generic. It may not always be desired for the WWJava component to own it's context and drawing surface. The awt package could be moved into a generic apps component / source root. Folks can still use it in conjunction with the core if it suites their needs. I however am doing something entirely different and don't need it for instance.

5. I have a platform for real time development in Java called Typhon. http://typhon.egrsoftware.com/ I haven't open sourced it yet, but I'm moving towards that direction (MIT license). OSGi seems like a good direction to move in regard to a component architecture. If done right it should support Eclipse Equinox, Felix and other containers. I'm working with Felix. I will release several components of Typhon that can be linked with the WWJava core to create some nice apps long before the release of Typhon.

I'm essentially creating a core WWJava component as an OSGi bundle that works nicely with Typhon. Doing so without forking is highly desired.

[ghchinoy]

Agreed, a wish/want list is great

I'd also like to see the OGL bindings be abstracted a bit so that SWT/LWJGL could be used.

Refactoring into discrete functional units (so bundle/plug-in ppl don't have to split up the SDK) would be great

Better documentation on getting data in and out of WW

More configureable preferences via xml

[TomServo]

Just remember.. a lot of this can be done outside the core API and should be. The core code should stay as small and streamlined as it can be.

[withak]

But if too much is done outside of the API then you have a tower of babel where no two WW clients can share data, or where commonly-used functions behave slightly differently in every client.

[patmurris]

Just remember.. a lot of this can be done outside the core API and should be...

Remember ?... well, if this is clear to you, just tell us what and how

[Guest_Jim_*]

TomServo's right I think. Isn't WWJava meant to be just the core program with plug-ins to do more than just render the globe? But there does need to be a standard or programmers willing and able to combine similar plug-ins into one.
Any way WWJava is a Beta SDK for crying out loud, don't make to many demands of it yet. In my opinion, stability, speed, and a correct interface should be the primary concern for the moment. An offline-mode would make sense at this point. Next then should be having it better work with WW.Net, such as being able to read its xml files and having access to its servers, and a standard plug-in architecture would make sense at this step. Keep in mind I'm not a programmer so I don't no if this could or should be how things are laid out, this just seems to make sense in my somewhat ignorant mind. I would still suggest one more thing though, start a wiki page, if there isn't one already, with these lists sorted by major, minor, useful, etc., but someone, who knows what they are talking about, should also sort through them to make sure they are indeed where they belong.
That's my two cents which probably doesn't mean much because I know so little about code and am happy at the moment for the fact that it is finally out.

[MichaelEGR]

Bombs away....

Heh... Not making demands here; statement of doing follows..

I'm actually going to go forward with the changes to the core I mentioned in my 1st post above. From my perspective these will enhance the core architecture and make it more generic/streamlined, less coupled, and independent of a particular GL binding and AWT. I would certainly be glad to discuss this work and will post the source when I'm done (probably this weekend if time permits).

I certainly would like to make contact with Tom or other supervising developers early in this process as it would suck to fork at this point, but I've got a vision for a more generic/flexible core that works for me ( and others most likely!

[TomServo]

Well, TomG does post here, his user name is TAG. You can also join the WWJava mailing list.. though that has been quite a few weeks now.

[Guest_Jim_*]

Heh... Not making demands here

Yeah, sorry. I've ranted like that before and generally feel stupid afterwards. If somebody else adds those features thats great, but I don't think it would be fair to force those ideas onto the WWJava programmers who are possibly concerned with other things. There will be a time though, I just don't think it is this time.
Again, sorry for my ranting.

[patmurris]

a lot of this can be done outside the core API and should be. The core code should stay as small and streamlined as it can be.

Thinking about it... maybe the way it is supposed to work is by beveloping other components beside the WWJ core to handle all - or some of the above features. That way a common set of tools/libraries could be made available with the SDK for developer to use in their applications.

For example, there could be a WW compatible layer loader module which could be used in conjonction with the WWJ core to make a WW compatible client. At least each application of the WWJ code would be able to use the same loader - if it needs to, to read WW XML layer defs...

Would that be the right way to go ?

[TomServo]

Yes, that is the way it most likely the way should be done. The core API should stay as trouble free as it can because it is meant for different uses, some using the API in their application may not want any of your suggestions; so they would have to remove them before they could use it.

But if you can just drop in all the tools you need, you can really start making your own customizeable World Wind globe. So almost.. it should be each large componet should be it's own. A developer may want one feature, but not another.

[patmurris]

Still... this is just guessing, for one thing, and which 'features' can or should be done outside the core is unclear.

I dont think you could add shading that way. WW cache compatibility cant be decided from outside either... or so i believe.

I'd really like to have some guidelines about all those questions.

[stolsvik]

Dependency Injection instead of static singleton WorldWind

I'd like WorldWind to be "IoC compliant", implying that one should be able to stack up all the different parts in consist of by means of programmatic or declarative "Dependency Injection", instead of the "big lump" that the classes WorldWind and Configuration along with their properties files now define. This is a very small architectural change, but may reap huge benefits in terms of modularity, code reuse, future proofing, testability and in particular embeddability.

I've written a feature request and started a thread on this.

I think when it comes to a "standard plugin architecture", DI will be a fantastic step in the right direction. This in particular if your needs are to use WorldWind as an embeddable component instead of as the sole application.