First demo of push with Nextcloud + DAVx⁵

[rfc2822]

I suggest these steps to get a first demo of DAVx⁵ with Push:

• Set up a test Nextcloud that we can use to test.
• Create a first demo Nextcloud app #10 (https://github.com/ArnyminerZ/webdav-push-nextcloud-demo)
• Create a first demo Push Director #11 (https://github.com/bitfireAT/webdav-push-director-demo)
  • send the push for any notification, so we can skip the Push Director subscription for now (DAVx5 still has to register for the topic on FCM side),
  • use an easy topic ID generation like md5(collection URL),
  • choose the language/framework so that it can be done most quickly. In the case of FCM-only for demonstration I think this can even be PHP: a script that is called on POST and then forwards the push to FCM.
• Create a first demo of FCM in DAVx⁵ #12
  • See https://github.com/bitfireAT/davx5/pull/367 for inspiration :)
• Create demonstration video (@ArnyminerZ)

I'd put code like the demonstration Push Director into this repository for now, too.

[sunkup]

Very exciting! Who gets to do which part? 😁

[ArnyminerZ]

Since @sunkup has already been working on davx5#367, maybe you can work on that part. I can take any of the second or third points, maybe the second one, which should be quicker, and then we can discuss how to do the PUSH director.

For the Nextcloud Server maybe we can just have local Nextcloud installations for testing, and once we have something solid to work on, prepare a testing Nextcloud instance for this purpose.

For topic generation I would suggest something SHA instead of MD5. It's known that MD5 has a lot of security issues, and it's also more resource-intensive, so I think it's better to use SHA1 or SHA256, depending on what we really want.

For language I agree that PHP would be quick for this test, but again it wouldn't scale well if afterwards we want to add the redis backend. ktor server is a good option, however maybe a bit of excessive boilerplate since we would have to configure a whole Gradle project. So Python or Go would be the next obvious choices. I don't really enjoy Python, but it works well for scripts, and it might be a good option. I think no one of us has worked with Go before, so I don't know if we want to take that language. There are of course a lot of languages to choose from, but this is my overview of the main options I can think of.

So TL; DR for the previous text, I would use Python for now.

What do you all think?

[sunkup]

Since @sunkup has already been working on davx5#367, maybe you can work on that part. I can take any of the second or third points, maybe the second one, which should be quicker, and then we can discuss how to do the PUSH director.

Don't mind continuing to work on the DAVx5 side. Thanks for taking care of the nextcloud internals, I am most afraid of that 😅 I also think we should all work on the push-director together, but I can make an attempt at an initial draft, which we then can work on together?

For language I agree that PHP would be quick for this test, but again it wouldn't scale well if afterwards we want to add the redis backend.

How would PHP not scale well when adding it to the redis backend? What exactly do you mean by that? I have used GO before and we could definitely use it for this, but since we are all most familiar with PHP I would opt for that. I don't really like python either, so there's that too 😉

For the Nextcloud Server maybe we can just have local Nextcloud installations for testing, and once we have something solid to work on, prepare a testing Nextcloud instance for this purpose.

I think @rfc2822 is best suited to take care of that :)

[devvv4ever]

Maybe we can also consider Rust for the Push Director, since it seems to be developed especially for network intense operations?

[ArnyminerZ]

@sunkup

Don't mind continuing to work on the DAVx5 side. Thanks for taking care of the nextcloud internals, I am most afraid of that 😅

Then I'll get started with the Nextcloud app ASAP, I've already taken a look at the insides of Nextcloud, but still a lot to learn.

I also think we should all work on the push-director together, but I can make an attempt at an initial draft, which we then can work on together?

Yeah, I think that could be a good option. Starting from a blank sheet of paper by a lot of people might be confusing, maybe it's best that someone starts developing the basis, and then we can all put out own ideas into it.

How would PHP not scale well when adding it to the redis backend?

My bad, I meant websockets.

I think @rfc2822 is best suited to take care of that :)

Yup, so as I said, something that we don't need to worry about right now.

---

@devvv4ever

Maybe we can also consider Rust for the Push Director, since it seems to be developed especially for network intense operations?

Yeah, it should also actually be quite performant. However I've never worked with it. Maybe it's time to do so 😋

[sunkup]

uuh, so after having dug deeper into the different languages, this is my current understanding. Please correct me if I am wrong:

• PHP: interpreted (therefore slower), no native web-socket support (!) and weakly-typed :(
• Kotlin+Ktor: basically java, so just-in-time compilation, which has slow(er) startup, but might be fast enough for us once it runs?
• Go: perfect for micro services, faster than Kotlin/java (because pre-compiled), strong focus on web APIs and relatively easy to learn (I have written Go code before)
• Rust: also good for micro services, hands down the fastest, but MUCH steeper learning curve than Go and we need/should(?) find a framework like actix, tide or similar ...

Kotlin, Go and Rust each have some kind of efficient concurrency mechanism.

PHP being interpreted and weakly typed irritates me somewhat and I feel most "at home" in kotlin now, so I would be happiest to go with Kotlin+Ktor. I guess it would be fast enough as well. In case we really need something faster: Rust looks very hard to learn, so I would always prefer Go over Rust. :)

I would like to hear @rfc2822's opinion on the language of choice, before I try an initial implementation for the push director.

[ArnyminerZ]

Yup, I agree with everything. Maybe we don't need as much performance as what Rust offers, in comparison on how hard it would be to learn. I'd also go with Go or Kotlin, let @rfc2822 choose

[devvv4ever]

Goal of this task is a video demo that shows the an event entered in Nextcloud, then maybe the POST request to the push director (for instance in the web server logs) and then on the phone with DAVx5 the calendar app that is updated automatically.

[rfc2822]

See #25