-
Notifications
You must be signed in to change notification settings - Fork 10
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
New name #27
Comments
Maybe just change what DVB stands for?
|
I like the first one^^ It's just a bit too German. "Digital VVO Bridge" however wouldn't be a good fit, since ideally this would go further than a single provider. |
|
I actually like Elon Musks take on acronyms and would like to see a new name that is not an acronym. I don't have any ideas though ¯_(ツ)_/¯ |
In the tradition of taking already existing words to make sure you never find what you are looking for on the search engine of your choice (see Swift, Python,…), how about Bus? |
I'm currently thinking about going with Triassic, the english term for the time period which is called "Trias" in German. |
I think I'd also prefer going with rewrites of the existing libraries and keeping the current stuff around, just removing EFA as soon as that is gone. This is going to be fun^^ |
Since I've already started having fun with a new swift lib and a repo for a js version at least exists, I guess this can be closed. See https://github.com/triassic-park for more 🙃 |
dvbjs might not have been the wisest choice to go with, albeit being pretty descriptive for its use-case. I'm currently on the lookout for alternatives, especially in regard to an upcoming TRIAS migration. This should influence all client libraries possibly involving a move to a new github organization as well.
The best option would be going with something that's not specific to a single provider, like the VVO (or the DVB underneath that). I'm pretty sure the name TRIAS is trademarked and something close to IP-KOM-ÖV is neither internationally compatible nor sexy 😄
There's also public-transport-enabler, which is however built on top of EFA afaik, so it's not necessarily the same idea.
Or would it be a wise choice to keep the current implementations and start over entirely?
Any suggestions?
The text was updated successfully, but these errors were encountered: