XML standard for documenting and IDE interaction

Efried

Active Member
Request for Comments for a project documentation standard:
 
Please have a look at the XML exchange format. This way a whole project could be stored away.
The next step after defining a standard would be to develop an integrated development environment:
it should transfer all the data stored in the XML into the WC, resp. only changed data because of the flashing restrictions.
cheers
 
 

Attachments

Not a fan of overcomplicating things. Setting hard and fast rules, more layers, dictating what will and won't be done, by who, and seventeen thousand forms to be approved before you can attempt a bugfix.
 
WC is what it is.
It's got there by being lean and mean.
Updates have happened quickly.
Additional features have been included before you can say "Who else wants it?"
 
By all means, go ahead and develop a NASA-spec, XML-based IDE with a cast of thousands. Each change request to be approved by every person in the development and review teams, checked for interaction, backwards compatibility, resource implications, then put through the documentation approval team, signed off by the regression testing team before anything can happen... and when you've got it done, please post a link so we can have a look.
 
But please don't "demand" that CAI adopt some top-heavy, administrative and resource hungry model that will kill what we've come to know and love!
 
rossw said:
Not a fan of overcomplicating things. Setting hard and fast rules, more layers, dictating what will and won't be done, by who, and seventeen thousand forms to be approved before you can attempt a bugfix.
 
WC is what it is.
It's got there by being lean and mean.
Updates have happened quickly.
Additional features have been included before you can say "Who else wants it?"
 
By all means, go ahead and develop a NASA-spec, XML-based IDE with a cast of thousands. Each change request to be approved by every person in the development and review teams, checked for interaction, backwards compatibility, resource implications, then put through the documentation approval team, signed off by the regression testing team before anything can happen... and when you've got it done, please post a link so we can have a look.
 
But please don't "demand" that CAI adopt some top-heavy, administrative and resource hungry model that will kill what we've come to know and love!
 
Ok but may I anyhow ask what you think of the XML style? Is it readable and functional?
targets:
1. may comment each item
2. may define variables upfront
3. readable code, so we don't need much more than a coloring XLML-editor
4. functional for using xslt to extract the WC-code, temp sensor settings and notification strings to transfer into the WC
The uploader should retrieve data from the WC and update those having changed only.
thanks
 
Efried said:
Ok but may I anyhow ask what you think of the XML style? Is it readable and functional?
targets:
1. may comment each item
2. may define variables upfront
3. readable code, so we don't need much more than a coloring XLML-editor
4. functional for using xslt to extract the WC-code, temp sensor settings and notification strings to transfer into the WC
The uploader should retrieve data from the WC and update those having changed only.
thanks
 
I do everything you're "expecting" someone else to do and/or force on us, in nothing more than a plain text file.
I fully comment my programs, including details such as which inputs and outputs do what, along with details of what subroutines do, expect on entry, change and return on completion etc.
I use vi, although you could use vim if you wanted colour.
To extract the "code" I use sed, which is included free with virtually every unix and unix-like OS.
 
I really just don't get why every second post you make seems to be complaining that the WC isn't more like a $20,000 PLC, doesn't have particular features of a $20,000 system, doesn't have interface options of a $20,000 system and more-or-less demanding CAI do so or "risk losing market" etc.
 
What can I say... if the WC8 doesn't do what you want it to do, doesn't have the interfaces you want it to have, etc, then DON'T USE IT!
For the rest of us, it is a versatile, convenient, reliable, inexpensive device that fills a need. Does it have limitations? Absolutely. Are they a deal breaker? In some instances, for sure (and then we use something else). But generally they're excellent. I really would NOT like to see some hideously complex additional "interface layer" that will not be multi-platform become a "requirement". It would destroy the product (well, in my opinion and from my perspective it would!)
 
Got to agree with Rossw here. The beauty in the WC8 is it's simplicity. You can parse a text string just as easily as XML so no need for the overhead. As a side note, XML is too fat anyway, if I were advocating anything (but I'm not), it would be json.
 
Thanks for your negative responses which brushed my mind:
 
- I could imagine using the PLC for a larger roll out in future since we are negotiating bravely new features and you have erected a practical DIY solution for your production demand (I still have to implement that for me)
- But may be CAInetworks will offer a bare board solution without user interface, and additionally a library under commercial license, hopefully not at a price tag of 20,000
 
 
cheers
 
Efried said:
Thanks for your negative responses which brushed my mind:
 
No worries. No extra charge, either ;)
 
 
Efried said:
- I could imagine using the PLC for a larger roll out in future since we are negotiating bravely new features and you have erected a practical DIY solution for your production demand (I still have to implement that for me)
 
It could be a language barrier, but so far much of what you've posted to this forum seems to have been either uninformed criticism of a product you appear not to understand, or requesting (through threats of lost business) substantial and often incompatible (not backwards-compatible) changes to the product, or expecting additional hardware support for specific devices the product was never intended to support.
 
Do I DIY stuff? Absolutely. Do I write code to help me work around limitations of otherwise suitable products? Absolutely. I've certainly made suggestions for improvements and additional features for the product - but not at the expense of backwards-compat.
 
 
Efried said:
- But may be CAInetworks will offer a bare board solution without user interface, and additionally a library under commercial license, hopefully not at a price tag of 20,000
 
I wish you well with that. If you can get the product in a manner you want it, at a pricepoint you need it, all is well.
But that's my point too. We currently have a product that does what we want, at a price we are prepared to pay. Changing it - especially if it means that it no longer fits the "lightweight, multiplatform, inexpensive" niche it currently occupies, will be a retrograde step in my opinion.
 
rossw said:
No worries. No extra charge, either ;)
 
 
 
It could be a language barrier, but so far much of what you've posted to this forum seems to have been either uninformed criticism of a product you appear not to understand, or requesting (through threats of lost business) substantial and often incompatible (not backwards-compatible) changes to the product, or expecting additional hardware support for specific devices the product was never intended to support.
 
Do I DIY stuff? Absolutely. Do I write code to help me work around limitations of otherwise suitable products? Absolutely. I've certainly made suggestions for improvements and additional features for the product - but not at the expense of backwards-compat.
 
 
 
I wish you well with that. If you can get the product in a manner you want it, at a pricepoint you need it, all is well.
But that's my point too. We currently have a product that does what we want, at a price we are prepared to pay. Changing it - especially if it means that it no longer fits the "lightweight, multiplatform, inexpensive" niche it currently occupies, will be a retrograde step in my opinion.
 
 
I'm jealous that you may sleep well not thinking about troubles porting your IP to future platforms, and not being compromised by lacking security...
Standards are a means of creating critical mass. your business case  may not invalidate that.
 
We do offer business with part of our GUI code, so that they can modify it for having their own name and looking, then we generate a gui update file for them. When they buying new boards, they will just update gui with their own gui update file to make it work for them. 
 
In the WC32, it is even easier, since user can actually generate their own gui code and upload without us to be in the middle.  Because in WC32, gui and libraries are separate two parts.
 
It is harder to hack into webcontrol, because you can change both user name and password to anything you like. granted, WC8 does not have encryption, but if high security is your concern, you will need regularly change your user name and password.  The most secure method is to remove network connection, which WC8 can still operate without problem. WC32 will have IPV6 support in the future, still waiting our supplier Microchip to provide us new stack.
 
Ross has a point that if we added support for all the other things, then WC8 definitely will not be able to handle it.  We must then use more expensive parts to make it work.  Our answer to that is WC32.  For that reason, both WC8 and WC32 will be exist for different purpose.  Both boards currently allow field update for any new functions and features.
 
CAI_Support said:
We do offer business with part of our GUI code, so that they can modify it for having their own name and looking, then we generate a gui update file for them. When they buying new boards, they will just update gui with their own gui update file to make it work for them. 
 
In the WC32, it is even easier, since user can actually generate their own gui code and upload without us to be in the middle.  Because in WC32, gui and libraries are separate two parts.
 
It is harder to hack into webcontrol, because you can change both user name and password to anything you like. granted, WC8 does not have encryption, but if high security is your concern, you will need regularly change your user name and password.  The most secure method is to remove network connection, which WC8 can still operate without problem. WC32 will have IPV6 support in the future, still waiting our supplier Microchip to provide us new stack.
 
Ross has a point that if we added support for all the other things, then WC8 definitely will not be able to handle it.  We must then use more expensive parts to make it work.  Our answer to that is WC32.  For that reason, both WC8 and WC32 will be exist for different purpose.  Both boards currently allow field update for any new functions and features.
 
d'accord, waiting happlily for the WC32!
Security not only comprises lacking SSL but also combining it with the use of GET.
Regarding security I may offer application based security, however thanks to lacking IDE my work flow is not professional and thus I can only propose an algorithm (next month).
Last but not least you may have heard about the hacking of email accounts of yahoo clients in this forum. This may have been through standard log-in passwords yes, but the log-in password to the WC is transmitted unencryptedly?
W may never be be sure that the NSA has no backdoor on the WC to grab the email accounts which are not really secure on the WC8.
 
Efried said:
Last but not least you may have heard about the hacking of email accounts of yahoo clients in this forum. This may have been through standard log-in passwords yes, but the log-in password to the WC is transmitted unencryptedly?

W may never be be sure that the NSA has no backdoor on the WC to grab the email accounts which are not really secure on the WC8.
 
Put your tinfoil hat on and go to bed.
http login-passwords are never transmitted in clear text. Suggest you do some reading on the challenge/response. Or use a packet sniffer to observe.
 
WC32 does have POST support in addition to GET.  However, we don't have many feedback on how that POST best fit users need, since most other devices, like ISY and many others only accept GET. Although we sold out all the WC32 beta boards, if you want to purchase WC32 production boards, you can contact us directly.
 
WC32 has SSL enabled email, but we have not enabled SSL over HTTP, since we want to do that after TCP stack updated, which is waiting our supplier to finish its new stack V1.0 release. HTTPS can encrypt packets to provide additional security. However, nothing can stop super computer from decrypting any encryption these days. Not just NSA, but many with supercomputer access can decrypt any HTTPS easily.
 
Avoiding someone hijack your data packet is more important for communication security.  We can not provide any guarantee for WC8/32 not being able to be hacked. However, we have WC8 boards running our gate opening function for 3 years behind our firewall, it never had any issue.
 
CAI_Support said:
WC32 does have POST support in addition to GET.  However, we don't have many feedback on how that POST best fit users need, since most other devices, like ISY and many others only accept GET. Although we sold out all the WC32 beta boards, if you want to purchase WC32 production boards, you can contact us directly.
 
WC32 has SSL enabled email, but we have not enabled SSL over HTTP, since we want to do that after TCP stack updated, which is waiting our supplier to finish its new stack V1.0 release. HTTPS can encrypt packets to provide additional security. However, nothing can stop super computer from decrypting any encryption these days. Not just NSA, but many with supercomputer access can decrypt any HTTPS easily.
 
Avoiding someone hijack your data packet is more important for communication security.  We can not provide any guarantee for WC8/32 not being able to be hacked. However, we have WC8 boards running our gate opening function for 3 years behind our firewall, it never had any issue.
 
Many thanks that's very kind. I will wait some months developing another project where I could use the WC32. HTTPS  would be fine to test how the encryption overhead will put an control system at risk. You are absolutely right authentication is important, so next step could be VPN?
 
Efried said:
 
Many thanks that's very kind. I will wait some months developing another project where I could use the WC32. HTTPS  would be fine to test how the encryption overhead will put an control system at risk. You are absolutely right authentication is important, so next step could be VPN?
I think you need to look at other platforms like the Beagle Bone Black and the Raspberry Pi. you keep trying to turn the CAI boards into something more substantial because they don't fit your use-case. It sounds like you just need a more advanced platform.
 
Back
Top