5 ms·

> Reinventing the wheel is generally said to be something to be avoided, but there’s quite a bit to learn from actually doing it. It made me realize that I didn

> Reinventing the wheel is generally said to be something to be avoided, but there’s quite a bit to learn from actually doing it. It made me realize that I didn’t understand it as well as I could implement it from scratch. I wrote a bitmap image library in C a few months ago and when I realized that I was in too deep I just kept going because I can never abandon a project I start. I felt bad when I came out the other end because of all the time I spent on it that I could have spent doing other things and because I could have just taken a library off the shelf. In doing the exercise I did realize that what appears to be a simple and straight forward image format, at first glance, is actually ambiguously defined and full of edge cases. There was no way for me to know that when I started.

kovek 6y ago
I like to call these discoveries as unknown unknowns. It’s when not only the answer/fact is not known, but even the existence of the question/fact is unknown. In this case, not only the fact that the format is ambiguous (the answer), but also the fact that there exists something interesting/unusual about the format (the question). For example, you could have learned the answer if you could have searched “is there something unusual about the format?”, or even “is the format actually ambiguous?”, but those ideas were not present! Active mentors can help with this a lot.
ajsnigrutin 6y ago
...but, you learned something new, and hopefully had at least some fun...
swiley 6y ago
I think a better way to phrase it is that reinventing the wheel has very little business value. But IMO you can learn a lot reinventing things badly and correct software has little business value anyway.
- a1369209993 6y ago
  As the saying goes: we reinvent the wheel not because we need more wheels, but because we need more inventors.
folkhack 6y ago
> There was no way for me to know that when I started. Any format/protocol/RFC that's been around for a significant amount of time is going to be bastardized and bent to solve people's problems. Right now I'm going through that with RTSP. I did my best to try to avoid writing my own client/server implementation because I knew that I would be taking on the responsibility to run down the quirks, but after some major vendor problems here we are =( Just throwing this out there for folks new in their career: if it's been "a thing" for awhile you can almost guarantee that doing a full implementation against it is going to be time-consuming because of the quirks/edge-cases. If it's something common like handling bitmaps you can get ahead of your problem by reading open-source image libraries to get an idea of how much "edge-case support" you're going to have to dig through. I just don't like forcing myself through "clean-room"/from-RFC/from-spec implementations unless I professionally have to - they're almost always painful and impossible to time-manage.
- shorts_theory 6y ago
  What problems are you encountering with RTSP? I used GstRTSPServer for an open-source project (https://github.com/shortstheory/adaptive-streaming https://github.com/shortstheory/adaptive-streaming) and it's filled my requirements pretty well. RTSP clients on the other hand...are a much more difficult story.
  - folkhack 6y ago
    HA. Oh boy. Well. I sorta mis-spoke. I need to ship RTSP/RTP with hella-different stream profiles over WebSocket. Imagine slamming the entire RTP and RTSP datastream into binary packets shipped around via WebSocket only to have the packets reassembled in-order on the other end. RTSP isn't quite the problem, especially if I had your use case. I work in PSaaS (physical security as a service) which has really unique streaming circumstance where security + latency are prime. Also, there's tons of additional features I need from RTSP as well, ex: "hey give me a new I-frame right now". Unfortunately the RTSP spec is all over the place with my vendors... and throw the whole ONVIF WebSocket thing at it + trying to actually keep stuff cryptographically secure and welcome to my nightmare. I'm talking about craziness like not having an "ack" to the final "PLAY" command in the prelude but the server still shipping the data, packet parsers/fixers implemented in ECMA, browsers acting as the RTSP session client... unfortunately the list goes on. There's a lot of overlap with your world. I even have your project bookmarked + labeled "sane light-weight RTSP gstreamer implementation" from when I was in my research phase! Small world =) If you're interested you can check out the ONVIF streaming spec: https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf And the pipeline tech that most of my jazz is based on: https://github.com/AxisCommunications/media-stream-library-js https://github.com/AxisCommunications/media-stream-library-j... Thanks for being an open-source resource with well-documented work!!!

kovek 6y ago

I like to call these discoveries as unknown unknowns. It’s when not only the answer/fact is not known, but even the existence of the question/fact is unknown. In this case, not only the fact that the format is ambiguous (the answer), but also the fact that there exists something interesting/unusual about the format (the question). For example, you could have learned the answer if you could have searched “is there something unusual about the format?”, or even “is the format actually ambiguous?”, but those ideas were not present! Active mentors can help with this a lot.

ajsnigrutin 6y ago

...but, you learned something new, and hopefully had at least some fun...

swiley 6y ago

I think a better way to phrase it is that reinventing the wheel has very little business value. But IMO you can learn a lot reinventing things badly and correct software has little business value anyway.

a1369209993 6y ago
As the saying goes: we reinvent the wheel not because we need more wheels, but because we need more inventors.

folkhack 6y ago

> There was no way for me to know that when I started. Any format/protocol/RFC that's been around for a significant amount of time is going to be bastardized and bent to solve people's problems. Right now I'm going through that with RTSP. I did my best to try to avoid writing my own client/server implementation because I knew that I would be taking on the responsibility to run down the quirks, but after some major vendor problems here we are =( Just throwing this out there for folks new in their career: if it's been "a thing" for awhile you can almost guarantee that doing a full implementation against it is going to be time-consuming because of the quirks/edge-cases. If it's something common like handling bitmaps you can get ahead of your problem by reading open-source image libraries to get an idea of how much "edge-case support" you're going to have to dig through. I just don't like forcing myself through "clean-room"/from-RFC/from-spec implementations unless I professionally have to - they're almost always painful and impossible to time-manage.

shorts_theory 6y ago
What problems are you encountering with RTSP? I used GstRTSPServer for an open-source project (https://github.com/shortstheory/adaptive-streaming https://github.com/shortstheory/adaptive-streaming) and it's filled my requirements pretty well. RTSP clients on the other hand...are a much more difficult story.
- folkhack 6y ago
  HA. Oh boy. Well. I sorta mis-spoke. I need to ship RTSP/RTP with hella-different stream profiles over WebSocket. Imagine slamming the entire RTP and RTSP datastream into binary packets shipped around via WebSocket only to have the packets reassembled in-order on the other end. RTSP isn't quite the problem, especially if I had your use case. I work in PSaaS (physical security as a service) which has really unique streaming circumstance where security + latency are prime. Also, there's tons of additional features I need from RTSP as well, ex: "hey give me a new I-frame right now". Unfortunately the RTSP spec is all over the place with my vendors... and throw the whole ONVIF WebSocket thing at it + trying to actually keep stuff cryptographically secure and welcome to my nightmare. I'm talking about craziness like not having an "ack" to the final "PLAY" command in the prelude but the server still shipping the data, packet parsers/fixers implemented in ECMA, browsers acting as the RTSP session client... unfortunately the list goes on. There's a lot of overlap with your world. I even have your project bookmarked + labeled "sane light-weight RTSP gstreamer implementation" from when I was in my research phase! Small world =) If you're interested you can check out the ONVIF streaming spec: https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf And the pipeline tech that most of my jazz is based on: https://github.com/AxisCommunications/media-stream-library-js https://github.com/AxisCommunications/media-stream-library-j... Thanks for being an open-source resource with well-documented work!!!