Closed wilddeej closed 5 years ago
I couldn't agree more. Here's the summary after a brief inspection of the code. You might want to double check that this it correct.
Feature | Tweepy | Diaspy | WP | Mastodon | Shaarpy | ||
---|---|---|---|---|---|---|---|
Enable/disable | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
max_posts | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
post_include_content | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
post_include_media | ✓ | ✓ | ✓ | ✓ | ✓ | N/A | ✓ |
post_prefix | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
post_suffix | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
hashtags | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
user-defined hashtags | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
max_tags | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
tag_filter_opts | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
url_shortener | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
It looks like the Diaspy client already has user-defined hashtags implemented, but other than that I think your matrix is accurate.
On Thu, Dec 6, 2018 at 1:10 PM Aurélien Grosdidier notifications@github.com wrote:
I couldn't agree more. Here's the summary after a brief inspection of the code. You might want to double check that this it correct. Feature Facebook Tweepy Diaspy WP Mastodon Shaarpy LinkedIn Enable/disable ✓ ✓ ✓ ✓ ✓ ✓ ✓ max_posts ✓ ✓ ✓ ✓ ✓ ✓ ✓ post_include_content ✓ post_include_media ✓ post_prefix ✓ post_suffix ✓ hashtags ✓ ✓ ✓ ✓ ✓ ✓ ✓ user-defined hashtags max_tags ✓ url_shortener ✓
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/aurelg/feedspora/issues/38#issuecomment-445013153, or mute the thread https://github.com/notifications/unsubscribe-auth/AXIWhvgdfRWpvQJ-7MH9yLtGEhucs3fJks5u2Xm6gaJpZM4ZG6sE .
Indeed. Matrix updated.
Once PR #46 is merged, all clients will support user-defined hashtags, max_tags, and the new tag_filter_opts functionality.
Matrix updated.
url_shortener
row updated according to PR #47
post_prefix
and post_suffix
rows updated, PR #50
OK, I think we're to the point where it's down to implementing functionality in the individual clients. I'm going to start writing up issues for each, as I go.
WPClient
updated after PR #55
FacebookClient
updated after PR #56
LinkedinClient
uupdated after PR #57
DiasporaClient
updated after PR #62
ShaarpyClient
updated after PR #64
MastodonClient
updated after PR #65
(NOTE: This is probably more of a project than an issue, but I'm not sure how to reflect this differently, and am open to other options)
All implemented clients should support a defined "core" set of functionality, with variances only where it makes sense for a specific client platform that supports some sort of unique feature, or if there is no mechanism available to support a particular feature. This does not mean that every client will implement the core functionality identically, but as much consistency as possible should be attempted.
The core set of functionality is proposed as:
enabled
[already implemented]max_posts
post_include_content
post_include_media
post_prefix
[ref. Issue #14]post_suffix
[ref. Issue #14]keywords
max_tags
url_shortener
andurl_shortener_opts
I think the best way to approach this is by first implementing any/all functionality that will be needed by all clients (this includes Issue #30), including documentation of that functionality (Issue #36 - which will likely be an incremental process throughout this "project"). After finishing the common core implementation, going through each client in turn to fully implement all the core functionality aspects for that client, or understand (and document) where this is not possible. The client-specific implementation will necessarily require detailed understanding and access to the relevant client, and that should be part of the client-specific documentation as well, of course.
If this sounds like a viable plan, and once all details are understood and agreed upon, it probably then makes sense to
Thoughts?