I discovered the surprising POCO C++ Library (http://pocoproject.org).
Because the intent of the library is, as its web page enunciate: "The POCO C++ Libraries (POCO stands for POrtable COmponents) are open source C++ class libraries that simplify and accelerate the development of network-centric, portable applications in C++."
Does someone thought in porting this excelent library to the Netburner modules?
I really want to do it. Does someone see a technical impediment to do it?
Best Regards
César Verdes from Argentina
POCO C++ Library
-
thomastaranowski
- Posts: 82
- Joined: Sun May 11, 2008 2:17 pm
- Location: Los Angeles, CA
- Contact:
Re: POCO C++ Library
It looks like it expects a full posix system, with thread and process support. If the make/configure system is setup such that you can exclude components, it would be straightforward. If no, it'll probably be a mess.
Re: POCO C++ Library
No, it's not a posix system dependent. As its name suggest it's designed as a POrtable COmponet library. However, until now it was only ported to high level OS.
The library is a friendly objects framework that hides the platform dependent code with the bridge pattern (http://www.vincehuston.org/dp/bridge.html).
For example, there is a Thread object that publics its interface to the developers, and the platform dependent code is in the Thread_WIN32 and Thread_UNIX objects. Every platform dependent aspect are treated in the same way.
The amazing of this library is that implements a framework and solutions very similar to the .NET framework or Java classes, making easier a step further in the process of abstraction.
Besides, it could make possible to develop and debug complex application on the PC and easyly port them to the NetBurner modules, just recompiling the code.
The library is a friendly objects framework that hides the platform dependent code with the bridge pattern (http://www.vincehuston.org/dp/bridge.html).
For example, there is a Thread object that publics its interface to the developers, and the platform dependent code is in the Thread_WIN32 and Thread_UNIX objects. Every platform dependent aspect are treated in the same way.
The amazing of this library is that implements a framework and solutions very similar to the .NET framework or Java classes, making easier a step further in the process of abstraction.
Besides, it could make possible to develop and debug complex application on the PC and easyly port them to the NetBurner modules, just recompiling the code.
Re: POCO C++ Library
Let me state up front that this post contains a lot of unsubstantiated opinion. However, I too am very interested in higher level C++ library support for the NetBurner so I thought I would weigh in here with my rather lengthy opinion)
While I think the NetBurner could greatly benefit from a higher level C++ library (or libraries) that encapsulates many services I'm not sure the design goals of the POCO C++ Library would coincide with what many NB developers really want/need. (Admittedly, I know very little about this library -or other NB developers for that matter) In fact it may use memory/resource intensive techniques that may obviate its use on the more memory constrained platforms. For instance, NB has turned off support for exception handling by default because of the resource usage issue involved even if a single try/catch clause is never written. Does the POCO library use exception handling? Does it use RTTI? I'm not saying no-one develops NB apps with exception handling or RTTI (I've done both in special cases) but I think using those features may limit its appeal.
One main design goal of POCO seems to be platform independence. I think this is MUCH harder to achieve in the embedded world and I for one have never had an embedded project that needed to be ported to another platform.
Another question is what areas really deserve effort for maximum re-usability on the NB? For instance, in pretty much every NB project I do I need a TCP Server that runs in its own task and communicates with mailboxes and semaphores with the main event loop task. I also need a command parser/handler in every project. Therefore, in my C++ library I have classes to support this. I can also see higher level support for Interrupts, Timers, event handlers, GPIO, error logging, AJAX front end support (including a JSON parsing/generation- as opposed to the equivalent for XML) etc. I could even see how having a library that supported various A/Ds and D/As would be very useful (just not sure how achievable this is). I'm guessing these areas don't share much overlap with the POCO library.
I've been thinking about starting an open-source shared library for the NB. A couple of things have held me back.
1. I've never been involved in an open-source project
2. My general feeling is that most developers here wouldn't be interested in the project
3. Even if such a library existed I'm not sure how many developers would take the time to learn and use it.
Judging from questions and posts, most of the code developed for the NB seems to be C code written to compile in the C++ compiler. All of the example code provided by NB follows this format. I would venture to guess that the majority of developers for NB do not use virtual functions or class hierarchies at all. Nor do they use templates, the STL or even the C++ iostreams. In fact the default NB project settings don't even include all the libraries you need to use these features. I don't see anything inherently wrong with the mostly C approach and it probably works well on an individual project basis. It's not until you start developing multiple projects that you want a more easily extensible and reusable approach and turn to more advanced C++ features to get you there. (Actually that doesn't apply to iostreams and the STL - I think there is no reason those shouldn't be preferred over the non type-safe alternatives).
Of course I think the current state of development is self-perpetuating. Until there are more elaborate C++ examples and libraries that demonstrate the advantages of achieving DRY and SOLID development no one is going to be interested. Until they are interested, no one wants to go to the effort and expense of developing these examples and libraries. NetBurner at least provides the software tools, and hardware with enough resources, to make true C++ development possible. I know from experience that developing libraries for use by others can be much more challenging than developing them for yourself. One advantage of porting something like POCO is a lot of design work has been done for you.
While I think the NetBurner could greatly benefit from a higher level C++ library (or libraries) that encapsulates many services I'm not sure the design goals of the POCO C++ Library would coincide with what many NB developers really want/need. (Admittedly, I know very little about this library -or other NB developers for that matter) In fact it may use memory/resource intensive techniques that may obviate its use on the more memory constrained platforms. For instance, NB has turned off support for exception handling by default because of the resource usage issue involved even if a single try/catch clause is never written. Does the POCO library use exception handling? Does it use RTTI? I'm not saying no-one develops NB apps with exception handling or RTTI (I've done both in special cases) but I think using those features may limit its appeal.
One main design goal of POCO seems to be platform independence. I think this is MUCH harder to achieve in the embedded world and I for one have never had an embedded project that needed to be ported to another platform.
Another question is what areas really deserve effort for maximum re-usability on the NB? For instance, in pretty much every NB project I do I need a TCP Server that runs in its own task and communicates with mailboxes and semaphores with the main event loop task. I also need a command parser/handler in every project. Therefore, in my C++ library I have classes to support this. I can also see higher level support for Interrupts, Timers, event handlers, GPIO, error logging, AJAX front end support (including a JSON parsing/generation- as opposed to the equivalent for XML) etc. I could even see how having a library that supported various A/Ds and D/As would be very useful (just not sure how achievable this is). I'm guessing these areas don't share much overlap with the POCO library.
I've been thinking about starting an open-source shared library for the NB. A couple of things have held me back.
1. I've never been involved in an open-source project
2. My general feeling is that most developers here wouldn't be interested in the project
3. Even if such a library existed I'm not sure how many developers would take the time to learn and use it.
Judging from questions and posts, most of the code developed for the NB seems to be C code written to compile in the C++ compiler. All of the example code provided by NB follows this format. I would venture to guess that the majority of developers for NB do not use virtual functions or class hierarchies at all. Nor do they use templates, the STL or even the C++ iostreams. In fact the default NB project settings don't even include all the libraries you need to use these features. I don't see anything inherently wrong with the mostly C approach and it probably works well on an individual project basis. It's not until you start developing multiple projects that you want a more easily extensible and reusable approach and turn to more advanced C++ features to get you there. (Actually that doesn't apply to iostreams and the STL - I think there is no reason those shouldn't be preferred over the non type-safe alternatives).
Of course I think the current state of development is self-perpetuating. Until there are more elaborate C++ examples and libraries that demonstrate the advantages of achieving DRY and SOLID development no one is going to be interested. Until they are interested, no one wants to go to the effort and expense of developing these examples and libraries. NetBurner at least provides the software tools, and hardware with enough resources, to make true C++ development possible. I know from experience that developing libraries for use by others can be much more challenging than developing them for yourself. One advantage of porting something like POCO is a lot of design work has been done for you.
Re: POCO C++ Library
First of all I want to thank you for your thoughts and opinion, and I want to apologize for my limited undestanding about the Netburner modules filosofy and technology.
I'm an electronics enginee who have developed in the past some C++ applications for the PC platform. Now I face the challange to go back to the embedded world to develop a web SCADA application for a genset. All the system information have to be read from the dedicated controller of the machine using Modbus/RTU.
I'm delaying the purchase of the NetBurner Development Kit until my boss authorize the project. Perhaps this happens only at the end of the year.
Meanwhile, I want to start working on the project in my free time, basically because I found this project an excuse to enjoy play with machines and low level coding.
That's why I thought that it would be great to have a library which let me start the project on the PC to test and show the concept. This kind of library would be only useful in the case it permits a fast port of the application to a NetBurner Module.
I have used the POCO Library in a PC environment and I know it's a very interesting way to speed up the developement of a network oriented applications. Perhaps you are right and the POCO Library is quite big for a microcontroller environment, even with 2MB RAM and 8MB of SRAM.
After read your comments, I realise that a better way of achieving an aplication easy port from a PC to a NetBurner module is porting the NetBurner Libraries to a PC instead of porting a PC Library to the NetBurner modules. Are you agree?
Perhaps the genset Web SCADA is not aproved, but I want invest my free time in speed up a possible future developement, and code something usefull for other people.
Based on your knowledge about the real needs of the NetBurner developers, do you think that a platform for develop a network-centric application on a PC and easyly port to a NetBurner could be usefull to others? From your point of view, which is the best way to do it?
Regards
I'm an electronics enginee who have developed in the past some C++ applications for the PC platform. Now I face the challange to go back to the embedded world to develop a web SCADA application for a genset. All the system information have to be read from the dedicated controller of the machine using Modbus/RTU.
I'm delaying the purchase of the NetBurner Development Kit until my boss authorize the project. Perhaps this happens only at the end of the year.
Meanwhile, I want to start working on the project in my free time, basically because I found this project an excuse to enjoy play with machines and low level coding.
That's why I thought that it would be great to have a library which let me start the project on the PC to test and show the concept. This kind of library would be only useful in the case it permits a fast port of the application to a NetBurner Module.
I have used the POCO Library in a PC environment and I know it's a very interesting way to speed up the developement of a network oriented applications. Perhaps you are right and the POCO Library is quite big for a microcontroller environment, even with 2MB RAM and 8MB of SRAM.
After read your comments, I realise that a better way of achieving an aplication easy port from a PC to a NetBurner module is porting the NetBurner Libraries to a PC instead of porting a PC Library to the NetBurner modules. Are you agree?
Perhaps the genset Web SCADA is not aproved, but I want invest my free time in speed up a possible future developement, and code something usefull for other people.
Based on your knowledge about the real needs of the NetBurner developers, do you think that a platform for develop a network-centric application on a PC and easyly port to a NetBurner could be usefull to others? From your point of view, which is the best way to do it?
Regards