Cafe Duet Unaddressed Questions
![[Deleted User]](https://w3.vanillicon.com/v2/3a10a0892a0f16ae29457aac10432220.svg)
[Deleted User]
Posts: 0
What I have learned from this forum is that the Cafe Duet Software is not required in order to use Java modules with NetLinx code.
This brings about the following questions:
1. How do I get the Java Runtime Environment? Is it included in the Netlinx firmware?
2. What about the SNAPI? Is that included in the firmware aswell?
3. If the answer to both/either of the above are 'no', then obviously something extra has to be installed on the Netlinx boxes by us?
4. If Cafe Duet is only required for actually building the Java Modules, couldn't I do that with any Java IDE/compiler? I know this is a FAQ, but WHY can?t I? What are the specific reasons why would I spend $2000 on Caf? Duet?
5. Can the main program logic be programmed in Java, or does this still have to be don?t in the Netlinx language?
6. What is the deal with SNAPI? Apparently it maps NetLinx commands to java through the use of embedded commands and constants? So what if I design a new Java class using Cafe Duet - say "XMLWebService", how does SNAPI know about it? I can?t change or add to SNAPI, I assume? So how do I call methods in my new class from Netlinx code?
7. What sort of standard libraries does this version of Java come with? I know it doesn't have any GUI libraries, but what about my WebService in the above question? Are there libraries to help me do that? If not, can I install my own choice of Java libraries to allow me to interact with web services and more?
8. We have 45 NetLinx boxes that desperately need to all be completely recoded from scratch. I feel like I am wasting my time doing this with Caf? Duet when Caf? Duet 2.0 is coming. When is Caf? Duet 2.0 due to become available? Will it allow us to develop completely in Java, thereby eliminating the need for any NetLinx code at all?
I would be grateful to anyone?s contribution even if you only have input to one or two of my questions.
This brings about the following questions:
1. How do I get the Java Runtime Environment? Is it included in the Netlinx firmware?
2. What about the SNAPI? Is that included in the firmware aswell?
3. If the answer to both/either of the above are 'no', then obviously something extra has to be installed on the Netlinx boxes by us?
4. If Cafe Duet is only required for actually building the Java Modules, couldn't I do that with any Java IDE/compiler? I know this is a FAQ, but WHY can?t I? What are the specific reasons why would I spend $2000 on Caf? Duet?
5. Can the main program logic be programmed in Java, or does this still have to be don?t in the Netlinx language?
6. What is the deal with SNAPI? Apparently it maps NetLinx commands to java through the use of embedded commands and constants? So what if I design a new Java class using Cafe Duet - say "XMLWebService", how does SNAPI know about it? I can?t change or add to SNAPI, I assume? So how do I call methods in my new class from Netlinx code?
7. What sort of standard libraries does this version of Java come with? I know it doesn't have any GUI libraries, but what about my WebService in the above question? Are there libraries to help me do that? If not, can I install my own choice of Java libraries to allow me to interact with web services and more?
8. We have 45 NetLinx boxes that desperately need to all be completely recoded from scratch. I feel like I am wasting my time doing this with Caf? Duet when Caf? Duet 2.0 is coming. When is Caf? Duet 2.0 due to become available? Will it allow us to develop completely in Java, thereby eliminating the need for any NetLinx code at all?
I would be grateful to anyone?s contribution even if you only have input to one or two of my questions.
0
Comments
4*) Not having the product, I'm going on vague recollections here, I think you can develop them in any Java IDE, but you need Cafe Duet to package and integrate them in such a way that the SNAPI router can properly interpret them.
5) Not yet. It was stated to be a future goal, and is already way behind initial release estimates.
6*) My impression was more that SNAPI routed Java and NetLinx modules to their appropriate interpreters. I don't believe you can mix-and-match within a module.
7*) It's based on J2ME. Any NetLinx specific libraries I assume would be included.
8) If the need is urgent, I would go ahead and recode those boxes in NetLinx, using whatever Duet modules are currently available. I don't think Duet for main programs is anywhere near close to ready. It's not like NetLinx will become obselete either, and frankly, I haven't even seen that Duet modules offer a signifigant improvement over NetLinx modules yet. I absolutely would not hold off upgrades waiting to be able to redo thementirely in Java - again, it's not imminent, and when it does become available, you may want to give it some time to make sure it's mature enough for your purpose.
* Items that could use elaboration by somewone who uses Cafe Duet.
If anyone has more info on questions 6 and 7, please reply.
I have read the SNAPI document and it makes the following key statments:
STATEMENT 1. "The Standard NetLinx API (SNAPI) maps function and feedback calls in Duet modules to ICSP channels".
Ok, so that conforms with what Dave Hawthorne was saying IE: Java within a Duet module is simply mapped to the Java Interpreter.
STATEMENT 2. "SNAPI allows NetLinx programmers to utilize Duet modules in their NetLinx programs"
o....k....so it does two things then?
STATEMENT 3. "SNAPI allows NetLinx programmers to ....access the function and feedback of those modules through programming similar to programming they would use on an AMX device, such as a volume box."
Now this fits in with what I was eluding to. So is that a third thing that SNAPI does?
SATEMENT 4. "...the SNAPI mappings apply to the Standard API supported by each module"
This, I believe validates the content of my Question 6. IE: that statement infers that SNAPI knows about the charateristics of each individual Duet module, and if that's the case what if I make my own Duet module - isn't that the point of Cafe Duet? How does SNAPI know about my classes?
Additionally, the "Cafe Duet v1.7 - Users Guide" states:
STATEMENT 5: "Choose which methods you wish to override....the SNAPI router calls these methods to allow NetLinx applications to interact with the Java modele"
This is consistent with Statement 4.
I'm going to stick my neck out here and say that Cafe Duet seems to have been somewhat of a flop for AMX. **But it shouldn't be** Implementing Java is a brilliant idea as it can endlessly expand the possibilities for programmers who are currently limited by the Netlinx language. If Cafe Duet is not being taken well by the general AMX community, it will be for one of two reasons:
1. AMX altered, restricted, and bolted down the Java implementation so much in an effort to retain market share, that they subsequently eliminated any benifits that the language could bring.
OR
2. People who know the Netlinx language don't know, nor have any desire to know Object Oriented Programming.
Lets hope that reason 2 is the more accurate one.
It's expensive and does not offer anything that can't be done using existing code.
There is also a healthy distrust of any software version 1.0.
I'd love to use Duet and have studied j2me using eclipse so I can use it when the boss forks out the cash, but I fully understand his reasons as stated above.
I want to buy Cafe Duet. I actually don't care how much it costs. But I'm not going to buy it if it is completely useless.
I use Cafe Duet, but I have learned there are not many of us out there! For me, since I was new to AMX I figured I would learn the old and new right away.
DHawthorne basically spelled it out, it works, and just fine at that, but it doesn't gain you much. Programming a serial device is a lot of "Send_String", it hardly matters what language that is written in.
With that said, once upon a time I was an actual developer so I am more comfortable in the Duet environment. It just seems we often come across a device that has no module, or a very old one. We take these and re-write them in Java, that way they are written to a standard API, and if we ever choose, work with Visual Architect.
Of course if you REALLY want to play in Java, the classes are there to handle button events and basically do all of your mainline code, it just isn't detailed out.
Curt
Trikin
Being a Duet user, are you able to answer any of my questions above?
If so - thanks!
The current release of Cafe Duet is intended to be used to develop Duet Java modules. Future releases will open that up. I am not sure on the timing on those as I am not directly involved in those.
Most of -sg-'s questions seemed to be answered here. The one I see is the desire to use his own module. Based on the current implementation that module would need to be derived from one of the standard Duet interfaces. That interface would enforce a standard API based on the interface type. Custom additions are possible, but SNAPI would not understand them directly. Message based work-arounds would most likely need to be used.
If you have specific questions above this, I can get them to the right people to answer if they don't monitor the forums.
Cwpartridge, Foundation profile allows to use JDBC optional package (JSR 169). Device manufacturer (AMX) decides whether to include it or not. Is that included? I am wondering how database connectivity is implemented in Duet, since using i-DatabasePlus is cumbersome...
There is no database connectivity in the current Duet release, other than via existing NetLinx applications.
Chuck
I am really worring about database connectivity in AMX since PC based smart home solutions are getting ahead of AMX in minds of clients, and getting without any efforts - just by fact they are not "strangers" (PCs are everywhere).
What I can answer to my customer who have asked for AMX action log to be posted in his data warehouse for accounting? That he needs to setup an IIS specially for the purpose to be able to use database connectivity in a way as AMX did it (i-DatabasePlus)??? The customer has Linux environment and in no way would like to setup a dedicated Windows-based PC as i-DatabasePlus implied.
It is getting silly...
I am asked on the forums for a few times... In generally, can we accept a control system without accountability??? We are talking about security and energy saving... Now the customers are voting for AMX, but inability to provide history data will seriously affect AMX in the future, IMHO. A system without memory...
I had a talk with a prospective client and with our competitor who use a PC based smart home alternative project named "Pluto". In no way they are able to judge correctly between AMX and others. But, PC standards are ruled because they know PC, it is more understandable, it is usual (less scare than AMX "stranger") - so let it be... And why do they need AMX for such a price?
If you can, please bring the opinion to marketing guys. Though I doubt it will work... until it
too late... Thanks again.
As for database connectivity - my opinion is that it shouldn't be handled from the AMX code in most circumstances. This is the purpose of my initial questions.
Database access should be encapsulated in a discreet part of the application. This is the theory of the "N-Tier" application. IE: There is a presentation layer, a business layer, a data access layer and database. The business layer should be the AMX, however it is my belief that the AMX code should not be handling the data access responsibilities. Why? Beacuse you may have several independent AMX installations and the data aceess layer should not be distributed.
Perhaps you can now appreciate my original question about XML . I want to build my own data access layer (using another technology like .NET) and have it hosted on a web server somewhere. The AMX boxes send their data requests to the web server and the data access layer handles the interaction with the database. I belive that you don't want 100 AMX boxes all reading and writing to a database.
So, AMX, do you provide the libraries neccessary to send and receive XML over HTTP?
J2ME Foundation Specification v1.0a
java.io Provides for system input and output through data streams, serialization and the file system.
java.lang Provides classes that are fundamental to the design of the Java programming language.
java.lang.ref Provides reference-object classes, which support a limited degree of interaction with the garbage collector.
java.lang.reflect Provides classes and interfaces for obtaining reflective information about classes and objects.
java.math Provides classes for performing arbitrary-precision integer arithmetic (BigInteger) and arbitrary-precision decimal arithmetic (BigDecimal).
java.net Provides the classes for implementing networking applications.
java.security Provides the classes and interfaces for the security framework.
java.security.acl The classes and interfaces in this package have been superseded by classes in the java.security package.
java.security.cert Provides classes and interfaces for parsing and managing certificates.
java.security.interfaces Provides interfaces for generating RSA (Rivest, Shamir and Adleman AsymmetricCipher algorithm) keys as defined in the RSA Laboratory Technical Note PKCS#1, and DSA (Digital Signature Algorithm) keys as defined in NIST's FIPS-186.
java.security.spec Provides classes and interfaces for key specifications and algorithm parameter specifications.
java.text Provides classes and interfaces for handling text, dates, numbers, and messages in a manner independent of natural languages.
java.util Contains the collections framework, legacy collection classes, event model, date and time facilities, internationalization, and miscellaneous utility classes (a string tokenizer, a random-number generator, and a bit array).
java.util.jar Provides classes for reading and writing the JAR (Java ARchive) file format, which is based on the standard ZIP file format with an optional manifest file.
java.util.zip Provides classes for reading and writing the standard ZIP and GZIP file formats.
javax.microedition.io The classes for the generic connections.
Device SDK Documentation v1.7.156
Packages
com.amx.duet.devicesdk Provides device base classes and interfaces for defining devices and providing default device implementions.
com.amx.duet.devicesdk.base Provides base classes and interfaces used by other classes in the Device SDK.
com.amx.duet.devicesdk.component Provides device component interfaces and their corresponding default implementations.
com.amx.duet.devicesdk.component.advanced Provides device component interfaces and their corresponding default implementations.
com.amx.duet.devicesdk.type Provides type-safe enumerated classes and helper classes to support the component APIs.
com.amx.duet.devicesdk.utilities Provides device component interfaces and their corresponding default implementations.
NetLinx Device API Reference 1.5.0
Packages
com.amx.duet.core.master Provides low level NetLinx Device APIs and system level constants.
com.amx.duet.core.master.netlinx Provides low level NetLinx classes and structures and NetLinx device listener interfaces.
com.amx.duet.core.osgi Contains the Service class from which all Duet higher level objects are derived.
com.amx.duet.da Provides classes for encapsulation of various NetLinx device types.
com.amx.duet.driver Provides AmxDriver interface for additional functionality beyond OSGi driver interface.
org.osgi.service.device OSGi interface definitions for device discovery service.
Utility API Reference 1.5.0
Packages
com.amx.duet.core.registry Provides access APIs for the Duet Registry facility.
com.amx.duet.core.util Provides miscellaneous utility APIs.
com.amx.duet.util Provides Duet utility classes which implement standard NetLinx funcionality and Duet System properties.
org.jvftp.util
org.kxml2.io
org.kxml2.kdom
org.kxml2.wap
org.kxml2.wap.wml
org.kxml2.wap.wv
org.xmlpull.v1
That seems to be everything listed.
As for adoption of Java instead of Netlinx, I agree that currently it doesn't offer any major benefits over netlinx. The biggest advantage I see in writing device modules in Java right now is that I won't have to rewrite them when cafe duet allows complete systems to be created with Java. I really like the Java philosophy and implementation methods I have seen so far and I think it is a great fit for the control systems I design.
Jeff