Based on the feedback I got from the schedule that I posted, we need to add some of the other core services to the design schedule. I'm not sure where to put them just yet, but we'll proceed with the schedule as is by starting off with generating a list of requirements, use cases, user stories and assumptions. The goal is to have this list by the end of the week. I'm sure it will change slightly as the design moves on, but the point is just to have a guide for the rest of the design.

I'd like to have a chat session online, so we can speed up progress a little bit and brainstorm in realtime. Can we setup a time for later in the week? Does anyone know of a good free chat room that we can use and then save our chat session, so we can post it to the forum?

Let's start the discussion off now. What would you like to see in the next release of OpenJAUS? How would you like it to work? I have many ideas, but I'd like to open the forum for discussion first.

Thanks for any help you can give!
Tom

Hey Tom,

We talked about this a little before, but I would really like to try using Google Wave as a collaboration tool. Unfortunately it is still a closed beta product and I don't have any current invites. I guess I would like to hear feedback from people that would like to participate but may not be able to if we pursue the Google Wave approach at this time.

On the topic of ideas for the future:

1. Documentation - this is self-explanatory, but really the area OpenJAUS 3.3.x and prior releases was weakest in and therefore I think it should be at the forefront of our efforts (and so far I think your plan of strong design documents leading the documentation is a good one)



2. Ease of use - I really feel this has been a strength for OpenJAUS in the past and helped the adoption of the toolkit (that and being free)... we started off writing "the JAUS" for a bunch of mechanical engineering graduate students whom did not have a ton of experience or expertise in C/C++ programming. For that reason, it was imperative that we abstracted lots and lots of functionality from the end user and presented a clean, easy to use interface through which the most basic and redundant task (creating and managing SCs for example) could be done with relative ease. Over the years I think these features (like the Large Message Handler, Service Connection Handler and eventually the ojCmpt template) really grew more and more powerful and intuitive. This kind of design, with even more capability to extend/override/change default behavior, should be a cornerstone of all OpenJAUS efforts, imho. If it makes the library code more complex or hard, but eases the burden on a potential user, I am in favor of the added library burden.



3. Flexibility - I touched on this in the previous topic, but one area I feel we were amiss in the previous implementation was in giving the more advanced user choices. If you look at the list of todos, questions and FAQS topics from the first DevCon (which I have and will post in here because I think they would be a good thing to look over moving forward), then you can see that many people in that audience (which was very experienced JAUS developers) wanted flexibility, options and overall the ability to tune the system to their exact wants and needs. I think it will always be a tradeoff of simplicity over flexibility, but if we take good advantage of object oriented code (method overloading for example) we can hopefully create a simple default interface, but always provide a hook for the more advanced/experienced/crafty user to change the default behavior of the system.



4. Documentation - Did I mention documentation?

Just some early thoughts, hopefully others will join the discussion. I know Nick has already thrown out some good ideas, as has Joe Pulver on the topic of encryption (yes) and timing (definitely).

~Danny

From what I've read, Google Wave would be an ideal tool to use for the collaboration. Unfortunately, I'm not a beta tester yet, so I have no experience using it. I remember with gmail, once I got in, I quickly had more invites then I knew what to do with. If Wave is anything like that, we should be able to get invites for those that want in. Of course I am saying all this without actually being in myself, or knowing exactly how many developers would be involved in the collaboration.

Joe,

I don't have any invites at the moment, but when I get some (not sure how long it'll take, I've been in the beta for about 2 weeks) I'll try to get an invite out to you.

Anyone else that wants to join the discussion, let us know and we will try to get invites out as we can.

~Danny

Last night I tried to brainstorm as many use cases and requirements as I could in one sitting. I need to create a new document on our repository to capture all of these thoughts that are on the forum. Here is the list I came up with (in no particular order):

All OpenJAUS code should adhere to a common style format

The code style format should be compiled into an Eclipse style definition xml file, so developers can auto format their code to fit the group standard

User should be able to write a custom service by extending a base service class that provides a set of basic interfaces and extends the JSS core services.

The user should be able to encrypt a data transfer from one service to another

Data encryption should be abstracted from the user, but have configurable interfaces for customization if desired

All functions / methods in the code should be documented with Doxygen style comments so that an API document can be generated. (Assuming that a doxygen style will be selected prior to implementation, and that the style will adhere to OJ code format standards)

Functions / methods that are intended for direct use by the user should be compiled into an organized API document, that can be separated from other “private” method documentation, as not to overwhelm new users

The users should be provided with documentation that explains the general layout of the openjaus libraries and how they are organized

OpenJAUS should define a new kind of service that mimics a Java Interface Class or a C++ virtual class, which allows a service to implement a set of messages without inheriting any behavior. This allows for optional service interfaces to be inherited per the users requirements. Ex: A GUI Widget Service Interface would allow a user to add some GUI capability to a service, without interrupting the standard inheritance stack.

For simplicity, a JSIDL state machine should be managed by a single thread. Users should be able to integrate their own worker threads to execute application behavior, and also have the option of using the state machine thread to do work as needed.

JAUS messaging should support message priorities via priority queues

Priority queues should be configurable to support different amounts of messages or data, possibly message lifetimes within the queue, other capabilities may be desired. Assume that the priority queues can be extended to add more functionality in the future.

OpenJAUS should extend all JAUS messages with timing information to allow all messages to have timestamps. This timing information should persist beyond the transport layer all the way to the application layer to allow the user to determine what to do with it.

The user should be able to compile all required OpenJAUS runtime code into a single application, if desired. There should be no need to run a separate “node manager” application.

OpenJAUS should provide an implementation of the core transport service.

Users should have the ability to user different transport mechanisms. OpenJAUS should support at least JUDP, JTCP, and a custom transport mechanism using shared memory (JMEM). Assume that the JMEM will be abstract enough to bring to the JAUS working group for adoption into the standard.

Users should have the ability to choose and configure transport mechanisms at runtime. For example, users should have an option to specify if they want a certain message, set of messages or message class to be routed on a particular transport.

OpenJAUS should robustly support message transport for large data messages up to at least several MB in size. Ex: high resolution images. Users should have the ability to configure how large data transport is managed. Large data transport should not breakdown state machine behavior.

Users should have the option to configure different dynamic system configuration and discovery techniques. OpenJAUS should support the classic multicast methods that have been used in past JAUS ETG experiments, and also implement new techniques that use broadcasting and server based discovery. OpenJAUS should also support static configuration (i.e. manually setting JAUS addresses prior to runtime) And support options to disable discovery.

OpenJAUS Services should be robust to online JAUS transport address reconfiguration. This will allow services to come online without a valid transport address and obtain one without effecting higher level services

Any static configuration of the runtime system (i.e. through config files) should be well documented.

If possible a way to automatically generate documentation for config file configuration options should be used during development. This will allow the documentation to be updated easily, if any options are changed, added or removed.

It would be nice to have an application / service management capability that allowed users to use JAUS interfaces / messages to start / stop / restart applications or individual services.

OpenJAUS should provide a service access control mechanism that restricts exclusive control with some security measures (ex: permissions, usernames, passwords, allowed services, or service types, etc…)

I found a wave invite. Feel free to add my gmail address (jpulver) to any OpenJAUS related wave's.