I have fetched all Gmail mail using JavaMail API Imap protocol and show them in table format but now the problem is how show delete them?
on click that mail has to be deleted, all connection using protocol is lost and I want to delete that mail.
Once you lose the connection to the server, you're effectively operating in "disconnected" mode. The JavaMail FAQ has pointers to more information about how to handle disconnected mode with IMAP. Doing this well is a lot of work.
A simpler approach is to do your best to ensure the connection isn't lost unnecessarily, e.g., by calling Folder.getMessageCount at least every 30 minutes. If you still lose the connection (which will happen sometimes),
you toss all your cached data, reconnect, and refresh the user's view.
If you only care about being able to delete messages that the user can see, you might be able to take an intermediate approach. You could save the UID of all messages (and the UIDVALIDITY of the Folder) and when the connection is lost you would reconnect and get the Message objects for all messages based on UID. Then you would be able to delete the message, if it still exists on the server.
Related
I am a bit of a bind when it comes to this topic. Here's my situation, I have a discord-like style of the app where you join chat rooms. I now have the issue of how to handle and use a local DB in conjunction with the remote DB. As I'd only load the newest X messages of the current DB and then if the user scrolls get the other X and so on. But where does a local DB come into the picture? For example, I stored in the DB messages from 10 AM - 12 AM, should I get the oldest message from the local DB and skip the timeframe in the remote DB when requesting the data? What if someone deleted/ edited a message? From my current standpoint, it really seems that just having a remote DB is the way to go
Using Nodejs Typescript and MongoDB for the server and the client is a Kotlin multiplatform app and I have access to a SQL DB on the client if necessary.
Also anyhow I approach this, since this is a chatting App and I already have an established Websocket connection, would loading messages and receiving them via the Websocket make sense, or should I make a REST endpoint?
Your localdb is effectively a cache, and you should treat it as such. Now that you have a cache, you have another problem, cache invalidation. Worse, since each client has it's own, you have a distributed cache invalidation issue.
You can probably sidestep a lot of this by making message immutable, and having a REPLACES_ID and an IS_DELETED field which allows an "edit" to really be an add which then from a UI standpoint replaces another existing message.. This will at least give you something fairly computable from a cursor standpoint.
Ideally your ID field is an increasing numeric sequence that allows simple queries like "Give me X messages from this room where ID is greater than [[The last id in your cache]]" If no data is returned, your local DB has all the data, otherwise take data from the query and populate your local database to bring these messages in.
Scrolling is more complicated, but in general can be ignored, nobody scrolls (statistically irrelevant number of people go to page 2). I'd recommend if someone scrolls just wipe the local database past the first page and go back to the remote server for X records BEFORE your current page's first record.
I've written a JavaMail client to access a GMail account via POP3.
As expected, I can only read a message once. When I re-run the client, the message is not found as it has been deleted from the server.
However, when I then log onto the GMail account (IMAP enabled) via a browser, the message appears.
Why does this happen? Are separate copies of the email created for POP3 and IMAP?
POP3 clients access the inbox, and what they see is unseen mail. When the POP3 client has seen a message it's no longer unseen and the POP3 server is supposed to do something.
The gmail server probably moves the message to the Archived folder.
You may have won a prize as the last person to have written a POP3 client, BTW.
Gmail has specific special handling for POP3 account:
In the default mode, it expects a 'download and delete' client. It will only expose 300 or so messages until those are DELEted. They are not actually deleted, but they are removed from the pool of messages to be sent through POP3. This prevents some of the inefficiencies with traditional POP3 clients accessing huge mailboxes, but does allow the client to eventually access everything.
The other mode is recent mode. You can use this mode by putting "recent:" in front of your login, like "recent:bob#gmail.com". This switches it to a mode where it will only show your client the most recent 30 days worth of messages. The messages do not disappear, until they fall out of the window. Again, this limits the size of the message list to a reasonable number for efficiency reasons, but in a different way. However, deletes can be synced between clients. (This may mean archiving in the Google Way). Recent mode is currently documented here in the troubleshooting section I want to download emails on multiple email clients.
Or, you could just use IMAP. Even without using all the additional features of IMAP, you can do everything you can do with POP3, but will allow many other features as your client evolves.
I am currently working on a web application using the MEAN stack. It has a social aspect to it so I want to be able to push notifications to users.
The way I do it now is when something happens that should be a notification it gets stored in a mongo database with an unread flag. Each client will send a get request to the server every 30 second and will receive every notification marked as unread, and will then mark it as read.
I want to switch to using a message queue and sockets so less network resources will be used, and also provide the user with a real-time experience. I've thought about using redis and its pubsub structure but I can't seem to figure out how to do this securely. If I push out notifications to the affected users, won't it be easy for someone malicious to subscribe to somebody else's channel and receive notifications not meant for them? Am I missing something or is it just the wrong approach for such a system?
Edit: Figure I update with the solution I went with if anyone else reading this is having the same problem.
Instead of using rabbitmq, as the answer suggested, I figured that a much more easy and elegant solution is to just use socket.io. When new sockets connects to the server I save a mapping from the userID to the socketId in a redis in-memory DB. (After I've validated their token) That way, if I need to push a notification to a user I just look up the socketId in the redis DB, and then send it to the correct socket.
This way I don't need any security beyond that as socketIDs are unguessable, and the message is only sent across the single socket that belongs to the given user.
This way it will only get sent through the connection of the given socket, as socketIDs are only used server side to keep track of all the connection. This means no one else can "listen" using someone else's socketID.
you can use RabbitMQ for this. Also authentication is there. Please go through following link and try.
https://www.rabbitmq.com/access-control.html
also, you can apply authentication in existing structure using subscription auth tokens with all subscribed users only.
even redis has its security with topics. Please have a look in link below
https://redis.io/topics/security
I'm working on a chat application and using socket.io / node for that. Basically I came up with the following strategies:
Send message from the client which is received by the socket server which then sends it to the receiving client. On the background I store that to the message on the DB to be retrieved later if the user wishes to seee his old conversations.
The pros of this approach is that the user gets the message almost instantly since we don't wait for the DB operation to complete, but the con is that if the DB operation failed and exactly that time the client refreshed its page to fetch the message, it won't get that.
Send message form the client to the server, the server then stores it on the DB first and then only sends it to the receiving client.
The pros is that we make sure that the message will be received to the client only if its stored in the DB. The con is that it will be no way close to real time since we'll be doing a DB operation in between slowing down the message passing.
Send message to the client which then is stored on a cache layer(redis for example) and then instantly broadcast it to the receiving client. On background keep fetching records from redis and updating DB. If the client refreshes the page, we first look into the DB and then the redis layer.
The pros is that we make the communication faster and also make sure messages are presented correctly on demand. The con is that this is quite complex as compared to above implementations, and I'm wondering if there's any easier way to achieve this?
My question is whats the way to go if you're building a serious chat application that ensures both - faster communication and data persistence. What are some strategies that app like facebook, whatsapp etc. use for the same? I'm not looking for exact example, but a few pointers will help.
Thanks.
I would go for the option number 2. I've been doing myself Chat apps in node and I found out that this is the best option. Saving in a database takes few milliseconds, which includes the 0.x milliseconds to write in the databse and the few milliseconds of latency in communication ( https://blog.serverdensity.com/mongodb-benchmarks/ ).
SO I would consider this approach realtime. The good thing with this is that if it fails, you can display a message to the sender that it failed, for whatever reason.
Facebook, whatsapp and many other big messaging apps are based on XMPP (jabber) which is a very, very big protocol for instant messaging and everything is very well documented on how to do things but it is based in XML, so you still have to parse everything etc but luckily there are very good libraries to handle with xmpp. So if you want to go the common way, using XMPP you can, but most of the big players in this area are not following anymore all the standards, since does not have all the features we are used to use today.
I would go with doing my own version, actually, I already something made (similar to slack), if you want I could give you access to it in private.
So to end this, number 2 is the way to go (for me). XMPP is cool but brings also a lot of complexity.
We have an browser application (SaaS) where we would like to notify the user in the case of internet connection or server connection loss. Gmail does this very nicely, the moment I unplug the internet cable or disable network traffic it immediately says unable to reach the server and gives me a count down for retry.
What is the best way to implement something like this? Would I want the client browser issuing AJAX requests to the application server every second, or have a separate server that just reports back "alive". Scalability will be come an issue down the road.
Because GMail already checks for new e-mails every some seconds and for chat information even more frequently, it can tell without a separate request if the connection is down. If you're not using Ajax for some other sort of constant update, then yes, you would just have your server reply with some sort of "alive" signal. Note that you couldn't use a separate server because of Ajax cross-domain restrictions, however.
With the server reporting to the client (push via Comet), you have to maintain an open connection for each client. This can be pretty expensive if you have a large number of clients. Scalability can be an issue, as you mentioned. The other option is to poll. Instead of doing it every second, you can have it poll every 5-10 seconds or so.
Something else that you can look at is Web Sockets (developed as part of HTML 5), but I am not sure if it is widely supported (AFAIK only Chrome supports it).