Unable to generate JSON from the newer .rst bluez documentation.
zelch opened this issue · 8 comments
Starting roughly in 5.70 (I think anyhow), bluez has been converting all of their documentation to ReStructuredText format.
The problem of course is that currently the code which parses the documentation to generate the JSON doesn't know about the new format.
This means that generation fails for 5.71, which is the current version in Debian SID.
Yes I noticed that and honestly I asked for this many times while the library was in active development. Unfortunately I do not have the time to refactor but PR are welcome.
I've got the parsing for groups (service, interface, object path), and methods sorted out.
Properties are next, and especially property flags.
At least currently, it's not horribly clean, and frankly it has some horrible hacks to work around inconsistencies in the document files, but it's getting towards functional.
Sounds great, looking forward to it!
Ugh, the parser is working more or less alright at this point.
But the generator is most definitely not, and some of the failures are going to be downright awkward to fix.
Specifically, in 5.71, there is one interface per file.
So you have:
org.bluez.MediaControl.rst
org.bluez.MediaEndpoint.rst
org.bluez.MediaFolder.rst
org.bluez.MediaItem.rst
org.bluez.MediaPlayer.rst
org.bluez.Media.rst
org.bluez.MediaTransport.rst
Instead of media-api.txt
This in turn means that even after we strip off the org.bluez., and make everything lower case, we don't just have bluez/profile/media/, we have bluez/profile/media/, bluez/profile/mediaitem/, and so on.
This isn't the only problem I'm running into, but it's one that I'm not sure how to fix without breaking the existing API.
Any ideas?
Alright, I sorted something out for that.
The commit message shows the evil in question. I'd be happy to implement a better way, if anyone can come up with one. :)
Great work, thank you! Let's see how it works. If you plan to use and impreve further the library, I could add you to the repo devs. Let me know
I'm definitely not opposed to the idea, though I'm not sure how much time and energy I'll have for it once I get my current target use case working the way I want it. :)
(I want to monitor a bluecharm USB ibeacon, and trigger commands based on presence/absence and/or signal strength. Which is surprisingly hard to do given the lack of a bluetooth connection.)
Yes sounds fair, thank you for the contribution so far!