Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make RustPad just-enough compatible with EtherPad URLs #79

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

ntninja
Copy link
Contributor

@ntninja ntninja commented Jul 19, 2024

Allows RustPad to work as a drop-in alternative for services that have basic EtherPad (popular collaborative document editing tool) integration using an IFrame

Really, it just extracts the two key pieces of information when invoked like:
https://path/to/rustpad/SomePadName?some=param&userName=AUserName&other=param
but that is enough to make it useful in the context of the “Collaborative Editing” (=EtherPad) support in the Jitsi Meet video conferencing solution. (SomePadName will be the name of the Jitsi Meet conference and AUserName the name of the currently logged in user.)

Based on #75, no real dependency through.

@ekzhang
Copy link
Owner

ekzhang commented Jul 20, 2024

Interesting, I like the idea! Down to merge this if the CI works.

… fragment

in the displayed URL if received like this
App state that doesn’t correspond to anything in the EtherPad documentation
has its own destinct names assigned.

Combined with the previous commit this allows RustPad to be opened as:

    https://path/to/rustpad/SomePadName?userName=AUserName&other=param

… which is just-enough compatible with Jitsi-Meet’s EtherPad integration to
make Rustpad a suitable drop-in replacement in that context.
@ntninja
Copy link
Contributor Author

ntninja commented Jul 23, 2024

I just found https://docs.etherpad.org/api/embed_parameters.html which documents the EtherPad parameter list and I found that aside from userName and the Pad name there is one more parameter with semantic overlap (userColor), so hue is now derived from that if it is set.

There are now also comments about the supported and unsupported parameters that should be helpful and I restructured the code to have all the URL handling in the now renamed useFromURL.ts rather than App.tsx.

Let me know what you think!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants