architecture doesn't promote community-wide collaboration?

[aspiers]

Hi there,

Firstly thanks for your great work on this project!

If I understand correctly from your README and from Tigge/openant#1, in the Linux Garmin syncing world, there seem to be 4 distinct challenges:

1. Downloading from devices by using the Garmin Device Interface Spec over an ANT-FS transport (necessary for FR405/410)
2. Downloading from devices via ANT-FS (necessary for FR60/310/610/910xt)
3. Uploading .fit / .tcx files to Garmin Connect
4. Building a user-friendly wrapper for the above operations, which offers a daemon mode and/or similar UX to the Garmin ANT Agent.

Bearing these in mind, it seems the following observations are true:

• This project currently addresses 1., 3., and 4., but not 2.
• GcpUploader currently addresses 3.
• https://github.com/Tigge/Garmin-Forerunner-610-Extractor currently addresses 2. but is being split into two parts:
  • https://github.com/Tigge/openant is a lower-level library for the ANT, ANT+ and ANT-FS which should make it easier to address 1. and 2. but will still require additional code which consumes the library API in order to implement full download support.
  • This additional code will be antfs-cli, which by use of a plugin system will address 1., 2., 3., and 4.
• There are other projects such as tapiriik which address 3.

Forgive me if I misunderstood something, but it seems to me that even though there is a large overlap in goals between this project and @Tigge's work, there is very little opportunity for code sharing, even though all the existing code is Python. I feel that the Linux part of the Garmin community is relatively tiny, and IMHO it would be a shame if this tiny community split into two fragments rather than working together on a universal solution. Is there a way that the two projects could be united so that we can progress much faster? Here are a few architectural suggestions:

• keep upload to Garmin Connect (3.) functionality as a separate project with interfaces which can be used by both projects (e.g. could be CLI or Python module)
• keep download from Garmin devices (1. and 2.) as separate projects
• standardize on a API for 1. and 2. so that any implementations of (1. and 2.) can be used as plugins by both this project and by the upcoming antfs-cli

I realise that in the short term this would require a bit more work, but in the longer term I think it could benefit our small community a lot.

Thanks for listening!

(This suggestion was prompted by the discussion in Tigge/antfs-cli#96. See also Tigge/openant#1.)

[Tigge]

I think there actually are some really big parts of the ANT/ANT-FS code that could be shared. If I understood this correctly python-ant-downloader and the older Garmin devices uses ANT and ANT-FS for search, pair, auth, but doesn't implement the 'file' parts of ANT-FS.

In the Garmin-Extractor (antfs-cli) case this is the layer where the majority of the code is. For reference, openant is ~3000 lines of code, and antfs-cli is ~500. I'd really like to cooperate, and especially on this layer. Perhaps it is possible for python-ant-downloader to use openant?

Other than keeping the ANT/ANT-FS code in a separate library I really wouldn't mind whatever other collaboration - even merging these projects.

[braiden]

Sorry for my slow reply.

There is quite a bit of common code. Ant as well as paring / session is all identical. The main difference is that once a connection is created with the watch the older devices I support us Garmin's old USB interface spec tunneled over ant, instead of ant-fs.

The bad news; during my research writing this software I signed up as an ant-fs adopter. I'm not a lawyer but accepting the adopter agreement makes me uncomfortable contributing to an open-source ant-fs implementation.

If you our anyone is interested in forking my implementation with ant-fs support, I can provide help understanding the code. I think you'd quickly look at my code and decide its ugly, and you prefer your own ant implementation.

[Tigge]

Sorry for my late reply. Vaction.

I've also signed the adopter agreement so the openant project is already 'tainted' by that so contributing to openant shouldn't really be a problem.

[braiden]

To keep things simple, I have to assign copyright to any future opensource contributions to my employer. I'm not comfortable doing that in ant-fs domain since I don't know how the adopter agreement taints my work.

If I find some time (which could be hard), I'll to try cleaning-up or port some feature-gaps to your project.

I think as far a implementing the my old protocol on another stack; its hard for me to justify the time. My software should obsolete itself in a couple years once there are no more 405/410 watches.