Closed MatthiasKillat closed 3 years ago
* [ ] Improve utils documentation (in the long run: find more suitable name for utils, e.g. safe building blocks), see also #468
I suggest iceoryx_hoofs
because that's what oryx stands on ;)
My second suggestion is zitzers
and my last one roadScorpio
.
* [ ] Improve utils documentation (in the long run: find more suitable name for utils, e.g. safe building blocks), see also #468
I suggest
iceoryx_hoofs
because that's what oryx stands on ;) My second suggestion iszitzers
and my last oneroadScorpio
.
+1 for iceoryx_hoofs
:D
* Introduction: motivation, goals and capabilities of iceoryx
I think it's a good idea to split the description in three major pillars. This makes it easy for newbies to clearly understand what the advantages are. The pillars could be reused for marketing. However, they are still up for discussion in #481 . Could we write the introduction divided into three chapters/pillars so we can link from the front page to them? What do you think?
All name suggestions are unprofessional and hard sells in my opinion but I mainly care about content, so whatever. Emphasizing safety as reason why we are implementing these (instead of just using STL in some cases) is important I think.
In other cases, i.e. lockfree constructs the reason is that it is/was not possible to find suitable implementations that work with shared memory and satisfy our safety constraints, so we created our own. Maybe this should be even an extra library.
All name suggestions are unprofessional and hard sells in my opinion but I mainly care about content, so whatever. Emphasizing safety as reason why we are implementing these (instead of just using STL in some cases) is important I think.
In other cases, i.e. lockfree constructs the reason is that it is/was not possible to find suitable implementations that work with shared memory and satisfy our safety constraints, so we created our own. Maybe this should be even an extra library.
If we want to go the route, we could have a iceoryx_cxx
, iceoryx_posix
and iceoryx_concurrent
repo. Everything that doesn't fit in those categories lands in the iceoryx_hoofs
repo
iceoryx_hoofs
or iceoryx_hooves
?
I thought the plural was "hooves" but apparently both are acceptable.
Or, if we are just throwing names out there, icicles
?
I don't have any other arguments other than it sounds cool to me haha.
@elBoberido as a first step I would not split this up in such fine granularity and would create only one separate repo for the utils. If later the need comes up to split it further we can do it but for now we should follow yagni (you aint gonna need it).
+1 for icicles. @ithier one question, the tests for the icicles would then be testicles? ;)
in a talk to @mossmaurice I mentioned iceoryx foundation classes
in short ifc
as possible name for the utils and he quite liked it
I guess that looks better than ~testicles~ icicles.
I still prefer HOOFS
<- Highly Optimized Objects (for) Functional Safety ... kudos to @mossmaurice for the nice backcronym
+1 for HOOFS
Another idea: {Helpful, Handy} Objects Optimised For Safety
update Readme of icedelivery_in_c (https://github.com/eclipse-iceoryx/iceoryx/pull/584#issuecomment-791340840)
Reopened due to open tasks
Documentation epic
Proposed outline
and_then
?)icehello
Documents covering
@todo
in the code shall not be linked to issues for v1.0v2.0 Release (Moved to #743)
Consolidate current documentation as far as possible (keep the scope of the issue confined to documentation). Note: doxygen documentation rework is out of scope here and belongs to #468
This is later to be integrated into the website #136