Re: [Jmdns-discuss] TODO List and Future Directions

[Arthur v. H. <av...@st...>]

Hi Dieter,

I'm not sure there are many people on this mailing list yet. The list is 
quite new. Here is some feedback.

Firstly I think that the goal of JRendezvous was to provide a simple an 
effective mechanism for Java apps to register and browser services using 
mDNS/Rendezvous. I think that the current implementation, given Java's 
limitations and some bugs, is quite adequate for that. Beyond that 
original goal I am not sure about the need for more functionality.

Here is my TODO list with a few additions. I'll add these to the task list.

- Improved efficiency in mDNS responses. In some cases it is possible to 
respond to queries more efficiently by grouping responses into one request.

- Asynchronous service registration. Currently the 
JmDNS.registeService() calls are synchronous which is annoying if you 
want to register multiple services in quick succession.

- Interface to a JmDNS daemon. If we use the same RPC mechanism as is 
used in Apple's Rendezvous we can interface to the daemon that ships 
with OSX. We can also provide a daemon implementation using JmDNS as an 
example.

- Asynchronous DNS name resolution. As far as I know there is no API 
available for asynchronous name resolution. Usually you need to fork a 
thread and called INetaddress.getByName() to make it asynchonous, this 
is inefficient and akward.

- Pass the Rendezvous test suite. I believe the library will need some 
minor modifications to comply more strictly to the standard.

- Create a more interesting sample application.

Dieter Wimberger wrote:
> Hello everybody,
> 
> I have been evaluating ZeroConf and in the middle of this process I have
> stumbled over jRendezvous while I was looking for implementations.
> 
> Now I would really like to utilize a standard instead of inventing something
> propietary, so I am willing to invest some work into this. Additionally I am
> already involved in the Open Source community and I like the idea of Open
> Source (especially for standard implementations).

You could be a great help. I have not done any open source development 
before and I have no idea to organize a reasonable development effort 
without stepping on each others toes all the time.

> I have already been in contact with Athur, but I guess it would be good to
> move discussions to the list, to enable the development in a community.
> 
> Arthur mentioned a TODO list, but I haven't been able to find it online.
> This would be a great starting point for people to help out with the
> development. 
> I guess for this list to become reality, it would be great to come up with
> some future directions. I have failed to do so many times in other projects,
> but maybe we manage to achieve it for JmDNS.

I have added some tasks to sourceforge to reflect my list of TODOs.

> Here some observations related to these future directions.
> 
> 1.  The specification establishes the vocabulary/glossary, so in many places
> it would probably be good to stick with this, although it is unfortunately
> sometimes pretty messy (with names especifically).

Sounds like a good idea. Please suggest how we should proceed on this.

> 2. The actual components of the mDNS and Service discovery cannot easily be
> identified from the existing code base.
> However, I think they (mDNS and DNS-SD) could be nicely separated:
> - For mDNS I think there could be a Querier and a Responder as well as a DNS
> Entry Database.
> - For DNS-SD you basically need a unicast and/or Multicast DNS Querier as
> well as an abstraction for a Service.

Internally this is already somewhat the case. The DNS functionality is 
not exposed in public APIs just because there was no need. I think it is 
a good to do this.

> I know that JmDNS started from Rendezvous and also that a lot of the
> functionality already exists. However, it would probably be good to
> reengineer it, as the above mentioned elements could also be used standalone
> (query a service, but have no responder etc.).
> They could also still be nicely unified via a Facade Pattern, so that
> nothing of the comfort available at this moment would be lost.

I'm all in favor of refactoring the code, but I need to understand more 
clearly what the goal is. I'm not sure that anyone other than the few 
people on this list care much about how it is done, as long as the code 
works well. I'm hoping that we can achieve your goals by making 
incremental improvements to the current implementation.

> Another point for reengineering could be an abstraction of the transport
> layer. I think this way DNS-SD could also become possible for J2ME level
> devices (embedded and probably also portable). By the way that is also a
> reason why splitting into components, because you could just deploy what you
> really need.
 >
> Now, I have already started to work a little bit on this, but I want to see
> what kind of ideas you guys have for JmDNS, to discuss and work on it as
> community.

I've mostly been working on a few outstanding bugs and the items on the 
TODO list. Let's coordinate so that we dont end up with a lot of conflicts.

Have fun,

     Arthur van Hoff