I'm working on the front end development of a custom mail system and at this point I've been using simple HTML to display data based upon my own received e-mails, however now I would like to create a table in my database of the information which is received upon connecting from on POP3/iPOP server.
Using Outlook.com you can rigth-click a mail and view source however I am oblivious to as whether this is the information gathered upon connecting.
I'm hoping this is the sort of question I can ask on here, basically I'd like to have an answer showing one example of all information received from the iPOP/POP3 server with information and/or useful resources.
To Clarify
I'm working on the front-end development and would like realistic information that would be gathered to create a dummy database table, thus meaning I can echo the information and create functions and whatnot prior actually establishing a connection to POP3 or iMAP
POP is a classic internet protocol in that it contains lots of plain text. You can use POP effectively using just telnet server.doma.in 110 to see how a server responsds to a particular command, and Wireshark will dump the commands user by Outlook and the server's responses, both in a format that'll suit your tests well.
Related
With my rails application, I'm supposed to provide following features:
There a limited number of users interacting with my system (in order of 10 to 20)
Like any normal mail client users should be able to have an inbox page showing received message, response to individual email and etc....
The mail client part cannot be an external application, they want everything packaged into a single application!
Normally These emails should be stored for future use
In order to send a receive email, we do not need to setup a mail server. They will provide the server and we will fetch the message with POP3 or something else. Same goes for sending emails.
The application itself often needs to look into these message as well, so it should be able to access corresponding email objects.
Separate part of these applications can be handled with individual gems such as Mailman, ActionMailer, and etc...
But what would be your suggestions to get this done?
I suggestion customizing an open source solution according to your needs. This is a gem/project that you should look at https://github.com/mailboxer/mailboxer It has all the features that you mentioned and its straightforward in its customizations.
I am working in a Rails application and below is the scenario requiring a solution.
I'm doing some time consuming processes in the background using Sidekiq and saves the related information in the database. Now when each of the process gets completed, we would like to show notifications in a separate area saying that the process has been completed.
So, the notifications area really need to pull things from the back-end (This notification area will be available in every page) and show it dynamically. So, I thought Ajax must be an option. But, I don't know how to trigger it for a particular area only. Or is there any other option by which Client can fetch dynamic content from the server efficiently without creating much traffic.
I know it would be a broad topic to say about. But any relevant info would be greatly appreciated. Thanks :)
You're looking at a perpetual connection (either using SSE's or Websockets), something Rails has started to look at with ActionController::Live
Live
You're looking for "live" connectivity:
"Live" functionality works by keeping a connection open
between your app and the server. Rails is an HTTP request-based
framework, meaning it only sends responses to requests. The way to
send live data is to keep the response open (using a perpetual connection), which allows you to send updated data to your page on its
own timescale
The way to do this is to use a front-end method to keep the connection "live", and a back-end stack to serve the updates. The front-end will need either SSE's or a websocket, which you'll connect with use of JS
The SEE's and websockets basically give you access to the server out of the scope of "normal" requests (they use text/event-stream content / mime type)
Recommendation
We use a service called pusher
This basically creates a third-party websocket service, to which you can push updates. Once the service receives the updates, it will send it to any channels which are connected to it. You can split the channels it broadcasts to using the pub/sub pattern
I'd recommend using this service directly (they have a Rails gem) (I'm not affiliated with them), as well as providing a super simple API
Other than that, you should look at the ActionController::Live functionality of Rails
The answer suggested in the comment by #h0lyalg0rithm is an option to go.
However, primitive options are.
Use setinterval in javascript to perform a task every x seconds. Say polling.
Use jQuery or native ajax to poll for information to a controller/action via route and have the controller push data as JSON.
Use document.getElementById or jQuery to update data on the page.
tl;dr What's the "right" way to get my data off an iPad such that only a researcher can receive and read it?
Full Explanation:
In my app, I've got to get the data from a database off the app and to a researcher. This will consist (most likely) of two separate files. The first will be table of identifying information:
ID FirstName ... etc.
This is sensitive identifying information that has to be sent so that only the researcher can get it.
The other will be de-identified info that uses ID numbers and the like, and it doesn't necessarily have to be secure, but I would like to only have it go to the researcher, obviously.
So far, I've only ever worked with data that can just be emailed, but there are some problems with this implementation. You can't just up and send an email; you can only present an email composition view ready to send, and then the user can edit the email before sending it. So a user could send this data to someone else.
Another wrench in the works: this researcher doesn't have access to a server, so I can't do SFTP uploads that way. It's also not guaranteed that the app will have internet access all the time.
The best idea I've got so far is to have a button to compose an email that attaches an encrypted file, protected by a password whose hash is hard-coded, I mean, compile-time provisioned, into the app.
EDIT: Here's what I'm going to do for the time being: use some personal server space so I can implement SFTP uploading, and then I will work with the researcher to get some server space they can use. Thanks for your answers.
Email is not particularly "safe" but if you just want to send email to one specific address, without the possibility of user intervening, you can use SMTP protocol yourself.
In one of my old apps I used skpsmtpmessage - I don't know if it still works, but if not there should be more solutions like it.
What it does is basically send email messages programatically, without using the composer dialog.
I'm just starting to learn about iOS development, and I figure the best way to get started is to build a simple (but non-trivial) app. My idea is this: have a web interface where a user can create a survey, and then access those surveys through the app and send responses back to the server. The web design part probably won't be terribly difficult -- I've done similar things with Django before. The part that will require learning/effort is the iPhone app.
I've got enough Objective-C that the data structures (model) won't be hard to code, and the UI (view, controller) part shouldn't be bad either. I predict that the interface between web and phone will be difficult, though. In particular, how will I be able to access the database on the server from the phone? I'd like to have a single DB that both web and phone apps use.
What I'd really like to have is a general, broad-strokes description of what I'll need to do to get this all up and running. Am I right in believing that the networking will be the hardest part? Are there any other possible snags? Any advice, or pointers to good resources on the subject, would be greatly appreciated.
Networking will probably not be the hardest part here, you're just guessing because that aspect is unfamiliar to you. For example, you can use NSURLConnection to take care of pretty much all the details of server connection. You can use NSJSONSerialization to convert your data to and from a format that is suitable for sending over the wire.
Basically what you might do is:
Mobile app sends a HTTP GET request to the server for survey info.
Server responds with a JSON description of the survey.
User fills out survey.
When done, the app sends the responses back in JSON format as a HTTP POST to the server.
Server stores the results in the database.
One of the key points here is that the app on the phone does not try to access the database directly. All requests go through your Django web app.
I am to build a web application which will accept different events from external sources and present them quickly to the user for further actions. I want to use Ruby on Rails for the web application. This project is a internal development project. I would prefer simple and easy to use solutions for rapid development over high reliable and complex systems.
What it should do
The user has the web application opened in his browser. Now an phone call comes is. The phone call is registered by a PBX monitoring daemon. In this case via the Asterisk Manager Interface. The daemon sends the available information (remote extension, local extension, call direction, channel status, start time, end time) somehow to the web application. Next the user receives a notified about the phone call event. The user now can work with this. For example by entering a summary or by matching the call to a customer profile.
The duration from the first event on the PBX (e.g. the creation of a new channel) to the popup notification in the browser should be short. Given a fast network I would like to be within two seconds. The single pieces of information about an event are created asynchronously. The local extension may be supplied separate from the remote extension. The user can enter a summary before the call has ended. The end time, new status etc. will show up on the interface as soon as one party has hung up.
The PBX monitor is just one data source. There will be more monitors like email or a request via a web form. The monitoring daemons will not necessarily run on the same host as the database or web server. I do not image the application will serve thousands of logged in users or concurrent requests soon. But from the design 200 users with maybe about the same number of events per minute should not be a scalability issue.
How should I do?
I am interested to know how you would design such an application. What technologies would you suggest? How do the daemons communicate their information? When and by whom is the data about an event stored into the main database? How does the user get notified? Should the browser receive a complete dataset on behalf of a daemon or just a short note that new data is available? Which JS library to use and how to create the necessary code on the server side?
On my research I came across a lot of possibilities: Message brokers, queue services, some rails background task solutions, HTTP Push services, XMPP and so on. Some products I am going to look into: ActiveMQ, Starling and Workling, Juggernaut and Bosh.
Maybe I am aiming too hight? If there is a simpler or easier way, like just using the XML or JSON interface of Rails, I would like to read this even more.
I hope the text is not too long :)
Thanks.
If you want to skip Java and Flash, perhaps it makes sense to use a technology in the Comet family to do the push from the server to the browser?
http://en.wikipedia.org/wiki/Comet_%28programming%29
For the sake of simplicity, for notifications from daemons to the Web browser, I'd leave Rails in the middle, create a RESTful interface to that Rails application, and have all of the daemons report to it. Then in your daemons you can do something as simple as use curl or libcurl to post the notifications. The Rails app would then be responsible for collecting the incoming notifications from the various sources and reporting them to the browser, either via JavaScript using a Comet solution or via some kind of fatter client implemented using Flash or Java.
You could approach this a number of ways but my only comment would be: Push, don't pull. For low latency it's not only quicker it's more efficient, as your server now doesn't have to handle n*clients once a second polling the db/queue. ActiveMQ is OK, but Starling will probably serve you better if you're not looking for insane levels of persistence.
You'll almost certainly end up using Flash on the client side (Juggernaut uses it last time I checked) or Java. This may be an issue for your clients (if they don't have Flash/Java installed) but for most people it's not an issue; still, a fallback mechanism onto a pull notification system might be prudent to implement.
Perhaps http://goldfishserver.com might be of some use to you. It provides a simple API to allow push notifications to your web pages. In short, when your data updates, send it (some payload data) to the Goldfish servers and your client browsers will be notified, with the same data.
Disclaimer: I am a developer working on goldfish.
The problem
There is an event - either external (or perhaps internally within your app).
Users should be notified.
One solution
I am myself facing this problem. I haven't solved it yet, but this is how I intend to do it. It may help you too:
(A) The app must learn about the event (via an exposed end point)
Expose an end point by which you app can be notified about external events.
When the end point is hit (and after authentication then users need to be notified).
(B) Notification
You can notify the user directly by changing the DOM on the current web page they are on.
You can notify users by using the Push API (but you need to make sure your browsers can target that).
All of these notification features should be able to be handled via Action Cable: (i) either by updating the DOM to notify you when a phone call comes in, or (ii) via a push notification that pops up in your browser.
Summary: use Action Cable.
(Also: why use an external service like Pusher, when you have ActionCable at your disposal? Some people say scalability, and infrastructure management. But I do not know enough to comment on these issues. )