From: Rick B. <ric...@ma...> - 2003-12-02 05:03:10
|
Hi Dieter, Glad you joined the list! I am going over your latest email, but would like to give you a bit of background as to the project. I was using JRendezvous as a standards based platform agnostic peer discovery service. I went back to update my code from Arthur's web site and found it gone! There seemed to be a problem with the name Rendezvous so they had to take it down. I contacted Arthur for permission to create a sourceforge project with his code and the JmDNS project was started. My goals for starting the project are pretty simple. I needed a light-weight standards based discovery protocol for several projects I am working on. I also think that the java community needs to have access to protocol implementations. Java is very heavy on API's, and a bit light on protocol. Which is understandable since Java is by and large a platform. However, in my work I must communicate to processes and systems in C and C++ on all types of platforms, so standards based protocols are what I look for. Examples of which are XMLRPC, XMPP (Jabber), SOAP, etc. So a chance to bring another protocol to the Java community was and is very appealing to me. I have not had time to create a projects web page. (I was sorta hoping someone else would do that). I basically agree with you on how to run an open source project. We (Arthur and I) modified the original directory layout only slightly and added an ant build script. I follow the Jakarta turbine project coding standards (http://jakarta.apache.org/turbine/common/code-standards.html) and would like to adopt it for this project. I think a very small light weight implementation would be great. I can see applications in mobile devices such as PDA's phones, Remote controls, home automation, where a very small light weight implementation would prove useful. This would be a case for breaking out the responder. More later as I digest your post. Thanks Rick On Monday, December 1, 2003, at 09:42 AM, Dieter Wimberger wrote: > Arthur, > >> I'm not sure there are many people on this mailing list yet. The list >> is >> quite new. Here is some feedback. > I thought so, but the good thing is that the list will be archived > automatically and that people can read back in case they are looking > for > info. > Also, you might probably want to check it out (i.e. how many people > there > are), the Mailman has a web frontend with administrative access. > >> 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. > I realized the idea of the package and I agree that this is what it > basically should do. Anyway, I think it could be more modular and thus > more > easy to deploy, maintain and extend. > With regards to the limitations, I think that with 1.4 there are some > new > things that might help (like for the problem of knowing where a > package is > coming from). However, here is where it would be great to have more > modularity, like for allowing to exchange "transport" implementations. > > Also as far as I understood you might not need a mDNS Responder on each > node, as well as it would also be possible to request services from a > standard administered Unicast DNS server, that is configured for > Dynamic DNS > Updates. Functionality you will need in all of these cases > are classes that know how to deal with DNS Messages, and an underlying > transport. > >> 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. > > As far as I understood you have two options: > > 1. You assume a local mDNS Responder and you add a service internally > to the > mDNS Responder database > 2. You send a DNS update message and handle the response > > If this should/can be made asynchronous depends a lot I say, > specifically in > For 2. I think synchronous is definately the better way, as you might > want > to have a response before you return control to the user (the > alternative is > an event mechanism, and requires more implementation work also by the > actual > "end-user". > >> - 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. > > What exactly do you mean with interface to the daemon? > >> - 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. > > Did not understand this either. Could you explain it better? > > >> - Pass the Rendezvous test suite. I believe the library will need some >> minor modifications to comply more strictly to the standard. > > Ok. Is there some information about this test suite somewhere? > >> - Create a more interesting sample application. > Some ideas? > I mean, I will try to use this for some stuff partially is already open > source. In case I get this going nicely, I will most likely include it > in > one of my projects. > > >>> 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. > > Where to start. From experience I think it would be best to have only > those > things in CVS that are really "source". I.e. anything you can generate > with > the build process shouldn't be in CVS. > > It's great to have a build directory instead of producing into the main > working directory (i.e. build/classes instead of classes). I guess in > some > moment you want to filter the source for the build, saw some > variables, so > you end up with build/src etc.). > > And here comes the bad news, well I think it is necessary to be as > modular > as possible, and to ensure that modules do their work (like with unit > testing). That's probably the best and only way not to step on each > other's > toes all the time. > One of the reasons why I suggested reengineering. > > I have been looking and testing a lot for my other projects, realizing > that > having something like Maven is great. However, when I tested it it was > too > much jakarta centric, and I switched over to something that is more > for the > documentation and far more flexible: Forrest > You can find it at http://xml.apache.org. It's a bit intimidating for > a fast > start and it seems as if the last release is broken (but a CVS snapshot > works). > If you want to see what you can do with it, take a look at > http://jpim.sourceforge.net > All you do is set it up and provide the content, the skin and > everthing is > generated..... > > Another good thing is to have a project guideline. Once you are at > jpim, > take a look at the one I adapted from jakarta (with their permission). > For a single person development it is overhead, but when there are > more.... > > Ah yes, another thing I guess would be good is to switch to another > package > naming. The "javax." prefix is supposed to be a Standard Java > extension. > A possibility is to use "net.sf.", another is to have your own domain > (or > using one we own). > >> I have added some tasks to sourceforge to reflect my list of TODOs. > Great. > >>> 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. > > Well top-down I would start with an interface for network services, as > well > as related classes (Service, ServiceTemplate and ServiceProperty). > The interface for network services plus it's implementation should be > the > Facade pattern I have been talking about, that is as easy to use as > JmDNS at > the moment. > Below could be possibly such an interface, allthough probably its > missing > something and it could throw Exceptions instead of returning null > values > (respectively empty arrays). > > > > /** > * > * @author Dieter Wimberger > * @version $version$ ($date$) > */ > public interface NetworkServices { > > /** > * Discover a network service matching the given > * service template. > * > * @param st a <tt>ServiceTemplate</tt> instance describing the > service. > * @return the service if discovered, null otherwise. > */ > public Service discover(ServiceTemplate st); > > /** > * Discover or wait for a network service matching the given > * service template. > * > * @param st a <tt>ServiceTemplate</tt> instance describing the > service. > * @param time the time to be waited for the service in ms, or > * -1 for endless. > * > * @return the service if discovered, null otherwise. > */ > public Service discover(ServiceTemplate st, int time); > > /** > * Discover all network services matching the given service > * template within a given timeframe. > * > * @param st a <tt>ServiceTemplate</tt> instance describing the > service. > * @param timeout the timeout for the waiting period. > * > * @return the services discovered or an empty array otherwise. > */ > public Service[] discoverAll(ServiceTemplate st, int time); > > /** > * Registers a given service.<p> > * > * @param s the <tt>Service</tt> instance to be registered. > * @return true if registered, false if the service instance name is > not > * unique. > */ > public boolean register(Service s); > > /** > * Unregisters a given service.<p> > * > * @param s the <tt>Service</tt> instance to be unregistered. > */ > public void unregister(Service s); > > /** > * Unregisters all services that were registered via this > * <tt>NetworkServices</tt> instance. > */ > public void unregisterAll(); > > }//interface NetworkServices > > I am working on the ServiceTemplate as well as Service (extending > ServiceTemplate) and ServiceProperty. > > I guess for the Facade only user, this would be all the interfaces > he/she > would need to be able to handle. Not much more complicated than at the > moment. > >>> 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 agree with this partially, for a front-end only user that's perfect. > But > that's also what patterns like the Facade are good for. > > However, probably things could be encapsulated nicely also at more > levels of > the package. I just think of the JmDNS class and the ServiceInfo > class. > Transport level details invade the latter and the first is basically an > example for a 1000 line, do-it-all-in-one class that make things hard > to > maintain. > I mean, it's great work, it works and everything, but probably it > could do > so also when split up into units (i.e. classes) with specific > responsibilities. Which I think would enhance maintainability and also > reduce the "stepping on the other's feet" symptom. > >> 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. > > Right, the goal I think would be to have units with specific > responsibility. > Making it fractal, this means packages with classes of specific > responsibility as well as classes with specific responsibilities. > > If we work top-down, we could see about first establishing the facade > with > an implementation based on the existing code. Parallel or afterwards > we can > start to work bottom-up and establish the transport layer as well as > the > Querier/Responder/Database layer. > At the end you simply swap the implementations, and that's it. > >> 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. > > See above. Hope I was clear enough, if not, let me know and I try to > explain > it better. > >> Have fun, > I'll do, hope you too :) > > > Regards, > Dieter > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Jmdns-discuss mailing list > Jmd...@li... > https://lists.sourceforge.net/lists/listinfo/jmdns-discuss > > |