If we position the Reference client similar to e.g. Reference Implementations to common JSRs, many of them (e.g. Cache, Glassfish for Java EE or even Pluto for Portlet) do not aim to provide an Enterprise ready implementation. In that sense a command line client for this one sounds reasonable and acceptable.
Since Eberhard's .NET clients or what's been "Console Example" for 1.0 demonstrated how to cleanly separate them, I am not sure, if it was a good idea to tie them together in the same way for an "Official client". For reasons mentioned earlier, e.g. the risk of a "back door" similar to standalone Java SE apps or Applets that often pose a security risk while proper Enterprise Containers are usually protected from such attacks. Werner On Tue, Aug 4, 2015 at 2:23 PM, Reza Naghibi <re...@apache.org> wrote: > > Are you planning some docs, or is that on the wiki already? > > The best way to answer this is to explain what the reference client is and > what real clients are. > > The reference client basically exists to validate, debug, and build domains > and provide a guide to how a real client should be written. This client > isnt really meant to be used directly by users. Its also meant to be > written very cleanly (hopefully) and make minimal use of Java idioms and > patterns. This is why I avoided maven and most 3rd party libs. > > So the reference client is likely to only be used on the command line. > There is a readme and a -h switch which goes over the params. There is also > the very detailed specification on the wiki which goes over what the client > does in fine detail. > > Outside of this, I dont see any other usecase of the reference client... > Let me know if there is a usecase im missing. > > Real clients are meant to be used by the users and should provide detailed > instructions on how to integrate with it and use it. Its upto the client to > define their own API. The specification defines what result should be > returned for a given input, the client is free to figure out how best to > turn that into an API. It would be very challenging to try and define an > standard API across so many languages. So until we actually have these real > clients, there isnt a way to integrate 2.0 into your software (unless of > course you hack the reference client into your Java codebase). > > As an example, it would be very trivial to port the reference client to the > official Java client. Add maven, restructure the classes, logging, etc, and > then release it like we did in 1.0. Also provide documentation and examples > on how to use it in your project. So this would be where you would see more > detailed documentation on how to use a given client in your project. > > Real clients should be written for performance, so I would expect that the > codebase would evolve to become more and more performant. The reference > client will always favor readability and being vanilla over performance. > Had we done a single Java client, over time this client would drift deeper > into the performance and Java realm and it would be very challenging for > new clients to be created based on existing correct clients. > > Let me know your thoughts... > > > On Tue, Aug 4, 2015 at 5:44 AM, Bertrand Delacretaz < > bdelacre...@apache.org> > wrote: > > > Hi, > > > > On Mon, Aug 3, 2015 at 6:13 PM, Reza Naghibi <re...@apache.org> wrote: > > > I converted the 1.0 xml device data to 2.0 json. So given we now have a > > > reference client, reference domains, our device domain in 2.0, and > > > everything came together as designed, I think thats enough to say we > have > > > an alpha release (pre beta).... > > > > Cool! As others have said it's not an Apache release until the PMC > > votes on it etc. but I see what you mean. > > > > IMO the compiled > > devicemap/clients/2.0/reference/devicemap-reference-2.0.jar shouldn't > > be checked in, the goal is to release source code only. > > > > Are you planning some docs, or is that on the wiki already? I have to > > admit that the whole thing is somewhat mysterious to me (in a cool > > way) by just looking at the code ;-) > > > > -Bertrand > > >
