Skip to main content

JXTA Usability Discussion

1 reply [Last post]
turbogeek
Offline
Joined: 2003-06-10
Points: 0

This topic is to solicite observations and solutions to issues of JXTA's useability by developers.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
turbogeek
Offline
Joined: 2003-06-10
Points: 0

I have been using JXTA for a very long time. My primary issues with JXTA usability is error propagation and understanding connectivity.

Before I start, it is not that you can't see an error or look at connectivity. The issue is in the usability surrounding these subjects. Both need a better programatic interface that is easily used by developers.

Errors can be things like connects/disconnects, and buffer overflows and such to advertisement de-serialization issues and malformed advertisements. The problem however is that many of these errors are just logged. The issue is that unless you wade through what can be a very large log with full knowledge of the JXTA platform, odds are you are not going to understand the severity of the message. In most cases exceptions are not propagated anywhere but these logs.

So two issues really. First, I don't know if my code is broken and I cannot tell if my peer or another peer is broken somehow.

A good example of this is with advertisements. If your advertisement does not de-serialize properly from XML, the only thing you may see is a log message. There is no way to hook into the cache manager to see if there are errors in the platform because of this issue. You can argue that this is because of bad code that is unproperly tested. However, the ultimate test is the platform itself and you need to add to this that advertisements can come from many sources. Knowing that there are critical errors will let e diagnose a problem. What is really needed is a programatic feedback to announce to client software that errors are occurring. Perhaps some of this is somehow available, but it needs to be easily configured and easily understood by the developer.

In a related issue we have connectivity. How do I know that I am connected? There are ways to do this to some extent, but it is not an easy thing to do. For example, what endpoints do I have enabled? And if I am going to or already connect to another peer, what is the route of endpoints? These are important to me for many reasons with the most important that I can understand message latency and bandwidth.

I also have no way to enforce the use of a specific endpoint or route. I'd like this capability so that I can cause my application to only connect between peers via a high bandwidth or even low bandwidth path. Yes you can do some work on custom peer groups but this is a nightmare (the whole group/module system is another great usability problem). The fact is that I should be able to make this decision when I create a pipe advert or when connecting the pipe. I should then have the ability to query the pipe to learn about its connectivity environment.

That's a start. Please add your own observations and solutions.

Message was edited by: turbogeek