lucastliu/gmailfs

filesystem based interface to interact with gmail

gmailfs's Issues

Make it easier for users to start by premaking directories

Currently there are some manual steps to create directories. It would be better if these directories were already made. This includes the client and cache directories.

Possibly related to config file issue #4

Example Task

do some stuff

Allow multiline body content in sent emails

Currently can only send one line of text in email. Change parser to allow multiple lines of text.

Advanced Support for Sending Emails

1. Create a folder where users can create and edit files (draft email). Implement corresponding FUSE APIs
2. parse email receiver, email sender, email subject line, email content
3. Send emails:
   3 possible ways
   • append a special string. e.g. <<<send>>>
   • when the user finishes writing the file, send the email in release()
   • move the draft to another folder

Split emails by having subdirectory in the inbox folder

If there are many emails in the inbox, have subfolders that each hold X emails. So if there are 10 emails, perhaps the first 5 emails will be in subfolder1, and the next 5 in subfolder2.

• have a config file to config the size of subdirectory

quick actions

enable ease of use options like quick reply

deal with replies and email threads

Cache does not handle emails that have moved around a lot while the program was offline

See title

Implement Cache

Implement a cache systCache most recently read (requested) emails

Cache (pre-fetch) the new emails

Keep the most recent 100 emails based on these 2 policies

We define “most recent” as:
For new emails: receive time
For old emails that are read: most recent user access time
Current plan: remove the cached emails on start up
Optional: After the program ends, cached email will remain and next time we will only update the new coming emails from the last execution.

indexing available emails is too slow

Calls api everytime, which is slow. Should just also have a metadata cache to store the available emails.

Cache deletion errors out

Deletion requires calling gmail API for email that no longer exists

Provide basic Gmail API interface

[Python]

Provide a way for the filesystem to speak with a real Gmail Account.

• Includes initial code for setup, account authentication, and service connection

M1

Hardcoded cache string

Code only works if you make your "cache" folder named "src"

This is due to 2 regex patterns that look for src/inbox

multiprocessing does not shutdown gracefully

after force closing the first time, on next startup, fuse is in an error state. Likely due to improper thread closing.

Cache size does not update immediately

Only updates once user opens a particular email, this may allow cache to grow without bounds.

Milestone 1 Demo

Full functionality for gmailfs demo with real gmail account

• Use gmailfs to see real list of inbox emails,

• Be able to read contents of specific email

• After receiving a real email, gmailfs reflects this update

• Can send a real email to another address

Unknown cache bugs

SSL error, could be API side or gmail side.

make premade folders hidden dot files

make premade folders hidden dot files and add them to gitignore

Add FUSE APIs to read email

1. store the message id in the stat data structure, and when user callcat filename, using the stat to get the message id

2. read() in Gmailfs class

• call gmail API to request a specific message in full format (get_mime_message)
• usef.write() write into actual file
• read the actual file to display the content

Get a list of emails from the inbox

Be able to see a list of emails from a real gmail inbox. Implemented by calling ls on the /inbox folder.

bugs:

• remove the quotation at the beginning and the end

Todos:

• store the email data somewhere on the local disk

Persist cache through restarts

Keep the cache in between restarts, just look for changes to update the cache, instead of clearing out and starting over

Remove Sender field from draft interface.

Sender should not be decided on each draft. It should just default to the main account associated in gmailfs.

path_type not handling all data paths correctly

Not handling client sending correctly

gmail API extend history updating function

Provide a way to (upon automatic update) give a list of which emails changed, and what the change was (new email or deleted). Provide email unique ID

Determine performance bottlenecks

Find out why it is so slow on the Duke VM. Works fine on local laptop.

Support Multiple Instances

Currently there is only one unique Pub/Sub. So if computer1 is running gmailfs, and ack's an auto update, computer2 will never receive the update on their gmailfs (even if same account)

Store an email as a directory

Create directories when we get the email list (instead of one file representing one email)

Each “Email’s personal directory” could have:

The email subject + unique ID will be the name of the directory

A file with the text content in html format

A file with the text content in plaintext format

Attachments are each their own file

Another file with all of the raw MIME data

Another file with all of the raw MIME data

inbox shows all emails, not just inbox

Need filter for inbox only, not all emails.
Need added filter in API calls, and additional logic within gmailfs to handle folders (aka labels)

Basic email sending function

1. Create a folder called "send". Send emails when users move their drafts to that folder. Users can only create files but cannot modify files. Implement corresponding FUSE APIs
2. parse email receiver, email sender, email subject line, email content

Emails are not configured to the correct datetimes

Dates on email files are incorrect. Some of them are from the future.

Enable config user's email account and pwd

• Have a config file(in a fixed format, defined by us) in the directory

• read config file in the __init__ in Gmailfs and pass it into Gmail object constructor

• possibly extend to other config options as well

• uses Google OAuth token instead of email / pwd

html format not always working / not showing content

may be related to emails sent from gmailfs to itself

Implement Automatic Updating

Need to automatically look for new incoming emails, and have any changes reflected in gmailfs.

Two options:

1. poll Gmail API every x seconds and just look at the recent emails

2. Develop a pub / sub function (watch API) whereby Gmail notifies gmailfs whenever there is a new email.

There are special cache implications for either of these choices.