Closed wilddeej closed 5 years ago
So in the case of implementing post_include_content functionality, it's more a matter of changing some logic so that this content is only included when the option is specified.
Exactly.
So it seems the post_include_media functionality will need to remain unsupported in this client, due to its nature/limitations. This should of course be mentioned in the FeedSpora documentation.
Yes.
Right now all posts to Shaarli are made public, but I can see the benefit of implementing a post_audience option that could be set to private to override this default behavior. This would be an easy-yet-useful feature to implement, and is planned for inclusion.
Yes, that would absolutely make sense.
[...] this is a good opportunity to generally clean up the client implementation, including the pylint errors. One of those errors is the assignment-from-no-return error associated with the call to the shaarpy.post_link API function.
I just accepted your PR on shaarpy
. Returning the token really makes sense.
I don't know if this ShaarpyClient
is used by other people. I personally use it a lot and it works really well. I'm glad you're planning to treat it as a first-class citizen: thanks!
Great! I'm moving pretty well with all of the Shaarli client enhancements, and will likely have them done today.
Working on this project has been a good learning experience for me in a lot of ways. One of those is that I've been exposed to some new social media services (I'd never heard of Shaarli, Diaspora, or Mastodon before), and I can see some interesting value from Shaarli in particular. I plan on investigating it further to figure out how I can take advantage of it, especially if I can streamline the entry process using plugins or whatever. It might prevent the need for me to keep so many Firefox windows/tabs open all the time for "stuff I need to keep accessible"!
It's also been pretty eye-opening to see what measures Facebook has put in place. I abandoned it quite a while ago (that's when I learned about Minds, actually), and it seems to be making itself less useful and open all of the time.
Working on this project has been a good learning experience for me in a lot of ways
I'm glad to hear it, and that's also the case for me :) Thank you very much for your contributions! :+1:
This is of course related to Issue #38. Only two features are missing from the existing Shaarli client implementation:
post_include_media
andpost_include_content
- and actually, the current implementation does include content by default. So in the case of implementingpost_include_content
functionality, it's more a matter of changing some logic so that this content is only included when the option is specified.From looking at the Shaarli documentation (and consistent with its purpose as a link-sharing service), it really has no facility for including media at all. So it seems the
post_include_media
functionality will need to remain unsupported in this client, due to its nature/limitations. This should of course be mentioned in the FeedSpora documentation.Right now all posts to Shaarli are made public, but I can see the benefit of implementing a
post_audience
option that could be set to private to override this default behavior. This would be an easy-yet-useful feature to implement, and is planned for inclusion.Finally, this is a good opportunity to generally clean up the client implementation, including the pylint errors. One of those errors is the assignment-from-no-return error associated with the call to the
shaarpy.post_link
API function. I think it would be best if that API function provided a return value, which would generally increase its usefulness, and that was what I had planned for this aspect. Two possibilities for this return value might be either the post "token" that is retrieved at the end of that function's successful operation, or perhaps the request result from which that token is derived would be more useful. Any input on this would of course be welcome.