Dit klinkt als een verstandige keuze. Vergeet niet om deze keuzes goed te beargumenteren in je PWS om aan te geven dat je hier over na hebt gedacht.

Heb je nog specifieke vragen waar ik je nu mee kan helpen?

Groetjes,
Joost

1. een studio omgeving - waar een vaste internetverbinding ligt
2. een live locatie - kerk, sporthal, theaterzaal etc. waar vaak een vaste internetverbinding ligt, maar de vraag is of deze van voldoende snelheid / betrouwbaarheid is.

Een nadeel is dat je hier op het platteland al snel in buitengebied zit waar vaak nog enkel adsl beschikbaar is. Een hotspot op de telefoon is een mogelijkheid, maar brengt zeker extra kosten mee.

Als je in de broncode kijkt op https://github.com/baltedewit/openintercom dan zul je misschien ook begrijpen dat er een extra reden is om niet voor optie drie te kiezen. Mijn client -> server beveiliging is niet optimaal, omdat ik gebruik maak van ongeregistreerde clients. Dat zou opgelost moeten worden met bijvoorbeeld tokens die verstrekt worden en gecontroleerd etc. Al met al een fikse uitbreiding van FeathersJS vrees ik.

Ik denk dat oplossing 3 de beste oplossing is om dit probleem zo goed mogelijk op te lossen, maar tegelijkertijd brengt het wel flinke nadelen mee. Ik ga me denk ik op het moment beperken tot oplossing 1, omdat ik daarmee de minste tijd besteed en ik altijd nog aan oplossing 3 kan gaan denken mocht er nog ergens wat extra tijd vandaan komen.

Mij lijkt optie 3 zeker het makkelijkst. Wat betreft optie 1 en 2 heb je denk ik gelijk.

Ik weet alleen niet precies op wat voor locaties je het systeem wilt kunnen testen/gebruiken. Tegenwoordig kun je overal natuurlijk wel aan een internet verbinding komen via een hotspot van je telefoon desnoods dus dit hoeft misschien geen probleem te zijn? De plekken waar je het wilt gaan gebruiken zou ik als voornaamste argument gebruiken voor één van de 3 keuzes.

Groetjes,
Joost

1 unregistered certificate

• Voordeel, turnkey solution. Project blijft toegankelijk voor minder geavanceerde gebruikers
• Nadeel: gebruikers aanleren om waarschuwingen weg te klikken.

2 local dns

• Voordeel, geen waarschuwingen.
• Nadeel, ingewikkeld om te installeren.

3 hosting in de cloud

• Voordeel, veilig certificaat, makkelijker te installeren dan dns, samenwerking meerdere fysieke locaties
• Nadeel, vps en domeinnaam is vereiste, internetverbinding vereiste.

Hierbij valt oplossing 2 wat mij betreft af, dit is namelijk niet flexibel inzetbaar. Oplossing 1 heeft ethische bezwaren, alhoewel de verbinding niet minder veilig is (omdat deze zich binnen het lokale bevind) leren we gebruikers aan om waarschuwingen van de browser te negeren. Oplossing 3 heeft als nadeel dat niet op iedere locatie een internetverbinding beschikbaar is. Het voordeel van oplossing 3 is dat meerdere fysieke locaties een intercom kunnen delen. Dus bijvoorbeeld een studio, een remote studio en een locatieverslaggever.

Mis ik hierin nog een oplossing, en wat zijn jouw meningen over de beste oplossing?

Helemaal goed! Ik wilde voorkomen dat je zelf met daadwerkelijke servers aan de slag zou gaan om tijd te besparen.

Veel succes!

Groetjes,
Joost

Dat ziet er goed uit! Is het een optie voor jullie om de Node server in de cloud te hosten? Bijvoorbeeld bij AWS of DigitalOcean?

Veel succes!

Groetjes,
Joost

Ik ben de afgelopen tijd bezig geweest met het schrijven van een concept. Hierin wordt denk ik je vraag beantwoord.

Het idee is om enkel de missing links tussen de open source projecten te schrijven. Kort gezegd is dat: FreeSwitch aansturen middels een NodeJS server en een gebruikersinterface bouwen.

In dit eerste concept is nog niks over hardware gerept, dat zal pas in een tweede concept na de herfstvakantie komen. Het idee is dan ook dat wat nu op papier staat zo rond de herfstvakantie ook in het echt zal bestaan.

Dit ziet er al aardig goed uit! Ik zie dat jullie al flink wat tijd in het oriënteren/onderzoek hebben gestopt.

Wat voor mij op dit moment nog niet helemaal duidelijk is, is welk onderdeel jullie precies willen gaan ontwerpen en welke onderdelen jullie "out-of-the-box" willen gaan gebruiken?

Verder neem ik aan dat het voor jullie nu vast staat dat jullie met dit onderwerp verder gaan?

Groetjes,
Joost

Excuses voor de late reacties. Ik heb dit project niet veel tijd gegund in mijn vakantie, maar nu begint het werk weer.

Als het goed is heb ik een bijlage geupload waarin in ieder geval een programma van eisen is opgesteld. Het daadwerkelijke concept laat nog even op zich wachten, zover ben ik nog niet met schrijven gekomen.

Het traject zal er ongeveer als volgt uit komen te zien:
vooronderzoek naar technologieën en opties => concept opstellen/bouwen/testen en itereren => uiteindelijk test in productie bij de lokale omroep => eindrapport schrijven

Het vooronderzoek en eerste concept zitten al redelijk in mijn hoofd, maar ik moet dat wel nog netjes uitschrijven.

Groetjes,
Joost

Wat ik me wel af vraag is wat voor structuur je in gedachte hebt voor je profielwerkstuk. Heb je al nagedacht over welk probleem je wilt oplossen of welke vraag je wilt beantwoorden? Heb je al hoofd- en deelvragen?

Ik denk dat het goed is om deze eerst op te stellen voordat je bedenkt wat voor praktisch deel daarbij hoort. Laat het me even weten en als je er niet zo snel uit komt kunnen we er altijd samen even naar kijken!

Groetjes,
Joost

op dit moment is het plan om de ontwerp cyclus te volgen.

het probleem wat opgelost dient te worden is dat digitale intercomsystemen te duur zijn in aanschaf, en analoge systemen niet flexibel genoeg zijn ivm verschillende locaties en meerdere kanalen.

Een uitgebreider programma van eisen kan ik je eventueel via de mail toesturen?

Groeten,
Balte