-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting Minutes
Lukas Röllin edited this page Nov 7, 2018
·
51 revisions
- What citation style should we use? Is [123] ok?
- How do we cite properly? For paraphrasing, is a citation at the end of a paragraph ok?
- What tense should we use for what parts of the thesis?
(AnneMarie is an English lecturer at HSR Rapperswil)
We approached AnneMarie with the topic of proofreading our study thesis. To see what our intended writing style is and what parts need improval, we sent AnneMarie the current state of our thesis.
She proofread this version until our meeting and suggested some improvements:
- Use a consistent tense
- Do not use contractions in academic writing
- Make sure citations are correct
What do you think about the code?
Looks good!
- How can we avoid https://github.com/dwrtc/dwrtc/issues/54
- TomP2P marks a peer as "non-reliable" when it detects issues with it. But this only applies to DHT operations. So, direct messages shouldn't be affected.
- Do we really need https://github.com/dwrtc/dwrtc/issues/52
- (Thomas replied to the issue directly)
- What about https://github.com/dwrtc/dwrtc/issues/59
- non-issue to us, so we're leaving it at the moment
- Started writing
- Some refacorings
Ask:
- Bachelor theses?
- Thomas has some ideas
- Code?
- Yes, please send
- How should we do the shutdown? Current idea is best-effort with destructor/finalizer
- Best-effort should be ok
- Basic stuff seems done
- Maybe a demo? But maybe we hit the demo effect, as usual (we also have a video for fallback)
Ask:
- We still have 10 weeks left (including this week). If we have a solution for deployment, is this all that needs to be done in this thesis?
- 3 weeks writing
- 3 weeks deployments
- 4 weeks polishing and more QA
- seems quite pessimistic...
- ==> Thomas sees some engineering tasks left
- Deployment
- Can we use TURN servers that are decentralized too (in a similar fashion)?
- Can we make TURN more robust, e.g. when one goes down it automatically switches to another one? (otherwise, the call drops).
- After that, we'll see if there's more time left to do, but otherwise this is about the size expected.
- Could we put our bootstrap servers under dsl.hsr.ch
- Would be ok for Thomas, but we'd have administrative/technical challenges. We'll start doing this on our own and maybe move it later.
- Can we check if TomP2P is bootstrapped?
- When the future is awaited, it should display a status. Maybe related to https://github.com/dwrtc/dwrtc/issues/27
Objective:
- Signaling for WebRTC works until next week
Ask:
-
objectDataReply
/sendDirect: multiple listeners?- multiple listeners are not supported, you have to write your own dispatcher
- Automatic ports choosing?
-
ports(0)
should let TomP2P choose its own peer
-
- Docker?
- TomP2P includes a mechanism that finds outer addresses. However, it may not work between multiple levels of NAT.
- AwaitListener / Await?
- We shouldn't use those, but use addListener
- Ideas for next steps?
- Polish GUI so we can have an example app
- Example app should also work over the Internet
Present:
- Proof of Concept
Ask:
- SA mündliche Prüfung
- Thomas will take it out
- sendDirect
- found an example by other students
- new API examples? API examples in general/"how to do X in TomP2P"
- use these
- Brainstorming additional features
- we and Thomas will think about it
For next week:
- Tell if we're on track for having a proper solution in 2 weeks from now
Present:
- Project idea
- Sounds reasonable
Open questions:
- Has the front page to be exactly as in the template?
- What's the specific project description (do we include an evaluation)?
- We'll get it later
- How granular do we have to track time? Is hours/category (~5) ok?
- Do what you want
- Use Kotlin instead of Java?
- Ok
- Is it OK to do the thesis in English?
- Ok
For next week:
- Write some of the project management stuff
- Design the architecture
- Write a really basic POC
- We checked codecs and such, and we found out that we wouldn't like implementing a (Java) GUI and send/receive media streams etc.
- We'd rather use WebRTC for that, but implement the signalling plane ourselves
- We came to the conclusion, that we could split this up. Priority 1: implement signalling plane (prepare both clients for an upcoming connection, exchange connection details, etc). Priority 2: maybe start the actual connection over this network
- There are some drawings to understand this idea further, but they're not yet ready
- Kickoff
- Discussed the scope of the project => should use TomP2P
- "P2P Skype" is still an option and we're gonna have a look at that first
- Until next week: