On Mon, Apr 25, 2016 at 11:25 AM, Joel Sherrill <j...@rtems.org> wrote: > > > On Mon, Apr 25, 2016 at 4:22 AM, Christian Mauderer > <christian.maude...@embedded-brains.de> wrote: >> >> Essentially I agree that it would be nice to build civetweb as an >> external library especially with the different network stacks in mind. >> But there are some points that keep me from doing it: >> >> 1. I have really no Idea what would be necessary to build it as an >> upstream project using RSB. If that are only something like three simple >> steps, it should be possible to squeeze it in the little time budget >> that is left for the project. If I first have to analyze and change a >> lot of RSB, it would be challenging. >> > FWIW I think this can be a secondary goal. Switching over to the real > upstream project with proper licensing is important. > > When we do this, we incur some burden of "retraining" users to consider > a webserver an external addon. But that is the direction I think we want > to head with httpd, telnetd, ftpd, etc. So it is a good long term goal. > >> >> Chris, I think you know the RSB best: What steps do you think would be >> necessary? >> > > Chris... > >> >> 2. Currently there is one test case for mghttpd (libtests/mghttpd01). >> This is one of the few tests that check some networking functions in >> RTEMS. Further we should not loose the ability to test software when it >> is build with RSB. How would we handle tests for software in RSB? >> > > That's a Chris question. We should aim to have tests which run with > either network stack for RSB built network services. This is a good > requirement on the plan to moving to separately built network stacks > and services. > > Having thought about this, I am not opposed to seeing the patches > merged as long as it is clear what is just moving to the new upstream, > what are patches, the patches are submitted upstream and we push > to get them merged. > > I realize you need a practical goal. I would like concurrence from Chris > and Gedare on the short and long term plans. If you can make any > progress on the long term plan, that's good but we should accept > the short term needed improvement. > > Perfection is the enemy of the good enough. > We need to watch out for incurring (new) technical debt. This patch set does not add new debt, but it does expose some that we had not thought about yet. I would certainly encourage spending some of your budget to consider the difficulty to provide the web server as a 3rd party package build, and to open a ticket to track such an idea. Since we now have examples of other 3rd party packages (e.g. graphics tool kit), I would expect that a web server should not be too hard. Plus, you get the advantage of not tying the civetweb build to the in-tree net stack.
>> >> Kind regards >> >> Christian Mauderer >> >> Am 23.04.2016 um 15:07 schrieb Joel Sherrill: >> > I am really with Gedare and Chris that it would be better to treat this >> > as an upstream project. Use the RSB and track patches through RTEMS >> > tools. >> > >> > It would be a good case to push the model of a single network service >> > supporting both stacks and begin the process of removing networking code >> > from the base RTEMS git repo. >> > >> > It would also push us to figure out how to rest RSB built packages. >> > >> > On Apr 22, 2016 12:05 AM, "Christian Mauderer" >> > <christian.maude...@embedded-brains.de >> > <mailto:christian.maude...@embedded-brains.de>> wrote: >> > >> > Yes that's right. 05/13 just adds the unchanged sources from >> > civetweb. >> > Beneath civetweb.c and civetweb.h it also adds handle_form.inl and >> > md5.inl. The last two files are included into civetweb.c. According >> > to >> > the documentation "The *INL* file extension represents code that is >> > statically included inline in a source file." >> > >> > And yes: The patch didn't get through. I have got a replay that >> > "Your >> > message to devel awaits moderator approval". The civetweb.c file is >> > over >> > 300k and the mailing list seems to have a maximum of 256k. I hoped >> > that >> > one of the mail admins would approve the patch soon. >> > >> > Am 21.04.2016 um 22:49 schrieb Gedare Bloom: >> > > I think patch 05/13 probably adds civetweb.c and civetweb.h? But >> > it >> > > did not come through the mailman. >> > > >> > > On Thu, Apr 21, 2016 at 4:46 PM, Gedare Bloom <ged...@rtems.org >> > <mailto:ged...@rtems.org>> wrote: >> > >> P.S. might be worth it to open a ticket related to civetweb and >> > >> #update it from these patches. >> > >> >> > >> On Thu, Apr 21, 2016 at 4:45 PM, Gedare Bloom <ged...@rtems.org >> > <mailto:ged...@rtems.org>> wrote: >> > >>> Is the plan eventually to be able to use the upstream civetweb? >> > or to >> > >>> track it with our own copy? >> > >>> >> > >>> On Thu, Apr 21, 2016 at 4:49 AM, Christian Mauderer >> > >>> <christian.maude...@embedded-brains.de >> > <mailto:christian.maude...@embedded-brains.de>> wrote: >> > >>>> This patch series replaces the mongoose webserver by its still >> > MIT >> > >>>> licensed fork civetweb. >> > >>>> >> > >>>> Please note that I try to get some (currently two) of the >> > patches >> > >>>> directly into civetweb too. But I think that it might need some >> > time and >> > >>>> adaption till they are accepted. So I thought that adding them >> > to RTEMS >> > >>>> would still make sense as a working interim solution. >> > >>>> >> > >>>> _______________________________________________ >> > >>>> devel mailing list >> > >>>> devel@rtems.org <mailto:devel@rtems.org> >> > >>>> http://lists.rtems.org/mailman/listinfo/devel >> > >> > -- >> > -------------------------------------------- >> > embedded brains GmbH >> > Christian Mauderer >> > Dornierstr. 4 >> > D-82178 Puchheim >> > Germany >> > email: christian.maude...@embedded-brains.de >> > <mailto:christian.maude...@embedded-brains.de> >> > Phone: +49-89-18 94 741 - 18 <tel:%2B49-89-18%2094%20741%20-%2018> >> > Fax: +49-89-18 94 741 - 08 <tel:%2B49-89-18%2094%20741%20-%2008> >> > PGP: Public key available on request. >> > >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des >> > EHUG. >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org <mailto:devel@rtems.org> >> > http://lists.rtems.org/mailman/listinfo/devel >> > >> >> -- >> -------------------------------------------- >> embedded brains GmbH >> Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel