Fred did a great job summarizing what I meant. Sometimes I fear I'm boneheaded; people don't necessarily understand what I'm trying to say!
I'd be somewhat happy if NEXT_LOCAL_PORT was allowed only in the DEFINE_DEVICE section. I'd be very happy if NEXT_LOCAL_PORT was allowed anywhere in code, such that I can create new ports at runtime.
And my proposed model doesn't change the "coherency" of the NetLinx language. The only difference is that (if NEXT_LOCAL_PORT can be called at runtime) the device array may change (i.e. new elements may be added). You'd still have a DATA_EVENT handler to handle I/O from that connection, and GET_LAST() can still be used to figure out which element of the array caused the data event to fire. You may have to do an extra step to rebuild the event table or something; I'm not sure on that as that's kind of "internal" to NetLinx today.
Let's call a spade a spade. In C++ or other languages, a socket connection is simply a handle. They're dynamic. You can create them, use them, and delete them as needed. You can have one connection or ten connections at the same time, and it doesn't matter.
In NetLinx, the same concept is a PORT (which is strictly a logical relationship between a data event handler and a connection to a machine that you specify at runtime). You can change the port at will in source code and, as long as it doesn't conflict with other ports, everything will work perfectly. The problem is that the PORT definition is static, defined at compile time. That that creates a host of problems.
By the way, WAY BACK at the beginning, NetLinx was supposed to at least get the concept of NEXT_LOCAL_PORT in the DEFINE_DEVICE section. For some reason, that fell off the radar, likely because of the compexity of the compiler working that out between different modules AND making static event tables (which was a restriction at the time). Things are better now, but I'm not sure this decision was ever reconsidered.
Originally posted by jeffaco And my proposed model doesn't change the "coherency" of the NetLinx language.
Exactly. I was just trying to accomodate in some way LCubed remark about your proposal being short of "absurd" by saying that keeping some coherence to the language was truly important, despite the different nature of Ethernet port. With the example, I tried to show your proposal did not necessarily mean a radical shift in the NetLinx paradigm.
But I agree the post was far from being that clear :-)
Anyway, yes if it is dynamic you have to use the new "REBUILD_EVENT" keyword. Very nice addition, thanks AMX!
Wow! I've been asking for Java support since the initial release of NelLinx. It's the best thing AMX could possibly have done (IMHO). It will be interesting to see what the resource hit will be.
I, too, wonder what the resource hit will be like. I wonder if AMX will need to come out with new ME-260's that have more memory (which goes quickly as your programs get very large, as I'm sure Fred has experienced).
While I don't know Java (I primarily do C++ or PERL - and sometimes shell - for scripting), based on what I've heard, it gives us a biggie of what we've been asking for here: Dynamic memory management.
If it can tie in with event management, it'll probably give me better socket handling as well.
I'll need to start poking around in Java once AMX releases their updates! ;-)
Actually Java gives us everything on the list except maybe reading level values (depends on the NetLinx java API). Yes the memory footprint and performance will suffer on current hardware. Java is typically performance and memory intensive. Expect a NXC-ME3000 coming up in the next future to make it really working for any real size deployment :-)
Funny, when typing the summary I was actually thinking AMX should not bother extending NetLinx but just port a C++ or whatever compiler to the platform instead of re-inventing the wheel. Should have written down at the time to sound more clairvoyant now :-)
It also explains why no one I guess from AMX even participated in this thread, with such a news waiting to be unveiled...
Originally posted by jeffaco If it can tie in with event management, it'll probably give me better socket handling as well.
You do not need event management any longer, except for TP pushes and RS-232 management. IP is taken care of natively with nice sockets in Java, which is also multithreaded, support a package notion (i.e. modules) somewhat similar to C++ objects (where you can control the visibility of everything from outside the object).
On top of it all we get an object oriented language with inheritance, list management ad nauseam, etc. As a very modern language, Java has all the latest bells and whistle in some form or another.
The trade off is it's slow (although we may not notice it so much with Netlinx which is somehow already interpreted) and it likes memory (as do all object oriented languages).
Comments
I'd be somewhat happy if NEXT_LOCAL_PORT was allowed only in the DEFINE_DEVICE section. I'd be very happy if NEXT_LOCAL_PORT was allowed anywhere in code, such that I can create new ports at runtime.
And my proposed model doesn't change the "coherency" of the NetLinx language. The only difference is that (if NEXT_LOCAL_PORT can be called at runtime) the device array may change (i.e. new elements may be added). You'd still have a DATA_EVENT handler to handle I/O from that connection, and GET_LAST() can still be used to figure out which element of the array caused the data event to fire. You may have to do an extra step to rebuild the event table or something; I'm not sure on that as that's kind of "internal" to NetLinx today.
Let's call a spade a spade. In C++ or other languages, a socket connection is simply a handle. They're dynamic. You can create them, use them, and delete them as needed. You can have one connection or ten connections at the same time, and it doesn't matter.
In NetLinx, the same concept is a PORT (which is strictly a logical relationship between a data event handler and a connection to a machine that you specify at runtime). You can change the port at will in source code and, as long as it doesn't conflict with other ports, everything will work perfectly. The problem is that the PORT definition is static, defined at compile time. That that creates a host of problems.
By the way, WAY BACK at the beginning, NetLinx was supposed to at least get the concept of NEXT_LOCAL_PORT in the DEFINE_DEVICE section. For some reason, that fell off the radar, likely because of the compexity of the compiler working that out between different modules AND making static event tables (which was a restriction at the time). Things are better now, but I'm not sure this decision was ever reconsidered.
Exactly. I was just trying to accomodate in some way LCubed remark about your proposal being short of "absurd" by saying that keeping some coherence to the language was truly important, despite the different nature of Ethernet port. With the example, I tried to show your proposal did not necessarily mean a radical shift in the NetLinx paradigm.
But I agree the post was far from being that clear :-)
Anyway, yes if it is dynamic you have to use the new "REBUILD_EVENT" keyword. Very nice addition, thanks AMX!
Fred
http://biz.yahoo.com/prnews/040910/daf014_1.html
It named DUET now. Will it get a name TRI... if it support .Net later???
While I don't know Java (I primarily do C++ or PERL - and sometimes shell - for scripting), based on what I've heard, it gives us a biggie of what we've been asking for here: Dynamic memory management.
If it can tie in with event management, it'll probably give me better socket handling as well.
I'll need to start poking around in Java once AMX releases their updates! ;-)
Funny, when typing the summary I was actually thinking AMX should not bother extending NetLinx but just port a C++ or whatever compiler to the platform instead of re-inventing the wheel. Should have written down at the time to sound more clairvoyant now :-)
It also explains why no one I guess from AMX even participated in this thread, with such a news waiting to be unveiled...
Fred
You do not need event management any longer, except for TP pushes and RS-232 management. IP is taken care of natively with nice sockets in Java, which is also multithreaded, support a package notion (i.e. modules) somewhat similar to C++ objects (where you can control the visibility of everything from outside the object).
On top of it all we get an object oriented language with inheritance, list management ad nauseam, etc. As a very modern language, Java has all the latest bells and whistle in some form or another.
The trade off is it's slow (although we may not notice it so much with Netlinx which is somehow already interpreted) and it likes memory (as do all object oriented languages).
Fred