Open ancestorak opened 10 years ago
The entire db could be quite large (16MB here and it was even bigger until I limited each feed to 30 past items) so maybe nsIZipWriter interface will be needed if the sync protocol doesn't compress the stuff automatically.
That's nothing, the database file can easily be hundreds of megabytes large (my own is over 600MB). But any sane sync protocol doesn't transfer all the data each time - just deltas.
Isn't the list of feeds already synced as a folder with bookmarks?
Yes, but Brief creates a home folder upon each installation and it's gonna be a different folder on each machine, so as it stands you would end up with multiple copies of your home folder. You wouldn't be able to fix it manually because you cannot change your home folder any more, either.
Then we probably need to ensure that Brief picks up the existing home folder automatically.
need to ensure that Brief picks up the existing home folder automatically
Maybe the places annotations service could be used to mark the home folder internally?
Then we probably need to ensure that Brief picks up the existing home folder automatically.
Yes, that's what I was referring to in my first post.
Maybe the places annotations service could be used to mark the home folder internally?
Good idea, seems like it could work.
:+1:
Actually Brief cannot just reuse the existing folder. As the user may enable Firefox Sync at any time, Brief may be already installed when the remote feed tree is synced.
In the least trivial case the local Brief has a non-empty local feed tree and a remote feed tree is synced down from the cloud. Brief needs to avoid the possibility of losing any local or remote feed and make it possible to integrate them cleanly.
@tanriol - I see your point, however this is a very well understood (albeit hard) problem in any syncing technology, so it's hard for me to believe there's not a way around it. Typically in case of conflicts, user interaction is required, so it may be for Brief too.
The real question - I guess - is if the intfrastructure for syncing exposed by FF supports this kind of things or not.
A small set of use cases that shall work as requested in #114
Alice has Brief installed on the home PC. She has bought a personal laptop, installed Firefox, configured Sync and wants to install Brief to see all the same feeds. The unread status, certainly, needs to be synced too.
Bob has Brief installed on the home PC and has received a work laptop. He has already configured Sync and now wants to install Brief for monitoring a completely separate set of work-related feeds.
Charlie has Brief installed on his personal laptop and wants to install it on the work one after installing Firefox and configuring Sync. However, he wants the work feeds to be available in a subfolder on the personal laptop in case he urgently needs to access them without the work laptop around.
Diana has finally decided to start using Firefox Sync between her desktop and her personal laptop. Brief is already installed on both. She wants to have a shared feed folder on both because Alice has told her that's a cool setup for her use case :-)
Eve needs to enable Firefox Sync between her work PC and her home PC to have some subset of her bookmarks shared between them. However, the work feeds are definitely not welcome on the home PC and vice versa. Actually, some of the work feeds should not be fetched from outside the work intranet as the security department doesn't like this.
Francisco is using Firefox Sync with a shared feed folder between two laptops. However, as one of them is going to be used for work only, he wants to create a separate feed folder on that laptop.
George, on the other hand, is tired of keeping two sets of feeds as they just overlap too much and wants to switch to a single one.
Thanks for the write-up. I think that having the same set of feeds across all devices is 1) probably by far the most common use-case 2) easily adapted to serve all the other use-cases. If you want to have different sets of feeds, then you can just group them into subfolders and fold the ones you're not interested in on particular device (folded state wouldn't be synced anyway). It is simple and workable enough.
Also, AFAIK none of the other major feed apps support switching between several sets of feeds, which I think is pretty telling.
If you want to have different sets of feeds, then you can just group them into subfolders and fold the ones you're not interested in on particular device (folded state wouldn't be synced anyway).
Which leads to the Today folder being useless in this setup. Maybe convert it into a filter like unread?
This also causes every feed to be fetched from every device. However, one may have different requirements depending on metered/unmetered internet access, for example. I've actually had a situation when opening Brief while tethering and a few image-heavy posts in the first page took my daily quota in under a minute.
Also, if we ever implement Brief for mobile Firefox, the previous issue will become even more nontrivial.
Anyway, this is not a pressing matter right now, so let's postpone it for now. The status quo is quite OK right now.
This also causes every feed to be fetched from every device. However, one may have different requirements depending on metered/unmetered internet access, for example.
It's a good point but I would argue that if you are using a metered connection then you should turn off automatic refreshing anyway. Therefore the above is only a problem if
In this case, if Brief supported separate home folders, you could afford to have Brief refresh feeds automatically instead of manually. However, it's not that big a deal to fall back to manual refreshing and I judge that this situation isn't nearly common enough to justify the complications if we were to support it.
Also, if we ever implement Brief for mobile Firefox, the previous issue will become even more nontrivial.
This won't happen for the foreseeable future, by which time limited data plans may be a thing of the past :)
Any news on this one?
Do we really need all the described use cases immediately? A lot less effort may be needed if we just sync the read/unread state of posts (with 'read' always winning) and we get nearly all the benefits. I, personally, subscribe/unsubscribe to feeds really rarely (so manual 'sync' of subscribed feeds is no problem) but read on multiple devices many times a day.
That would likely run into the storage limits as they're pretty strict.
Also that would require a significant amount of developer time to implement, which I don't have at the moment.
The most important part is to sync the list of subscribed feeds and read/unread status of items. We can investigate the feasibility of syncing the entire database, i.e. all the old items.