I am aware that 31st July has been noticed as the cut off but do them actually mean by midnight tonight?
We require all FORM vendors who are using an older protocol to upgrade to v3.00 by 31 July 2015 otherwise there is a risk you will not be able to process transactions.
How to upgrade: https://www.sagepay.co.uk/support/find-integration-document/migrate-to-v3
Please note, our MySagePay Virtual terminal is not effected for FORM users as v3.00 protocol is used through this method.
To find out what options are available to you, email upgrade#sagepay.com, for an immediate response.
Regards
Sage Pay Support
0845 111 4455
Related
Is there a batch Get messages? from the golang client library?
I dont see it
https://godoc.org/google.golang.org/api/gmail/v1
i can get a list of message ids, but have to get the message per Id, one at a time.
Answer
There is a Github issue on the Go client's repo regarding this topic, and apparently it is not likely to see support for this feature anytime soon. It may, however, be implemented in the next generation of the client.
Possible workaround
You can implement yourself the batching feature, by making HTTP calls to the www.googleapis.com/batch or www.googleapis.com/batch/api/version endpoints. The former is due to be deprecated in August 12, 2020 but you can still use the latter past this date for homogeneous requests (in your case, doing GET requests based on messageId, you should have no problem doing so). You can read more about this in the following Official Google Developers Blog post: https://developers.googleblog.com/2018/03/discontinuing-support-for-json-rpc-and.html
We are currently working on an app that uses pusher.com to maintain a list of available people on our chat application.
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work. Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
So far, here is what I'm considering:
XMPP/BOSH
socket.io (self-hosted)
pubnub
As for the scale, we will probably have to handle 100+ messages per second and 10000 concurrent users. Nobody here has ever played with socket.io (or bosh), and we do not wish to have too much maintenance work (ie deal with many servers and such). So 2 or 3 self-hosted servers is ok, 10+ isn't.
Any thoughts?
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work.
This is incorrect. Pusher (who I work for) provide fallback for older browsers. HTTP-based fallback has started to be released to go alongside the existing Flash socket fallback. So, older versions of IE were already handled with the Flash socket fallback but the HTTP-based fallback will give near 100% browser coverage.
The November 2012 issues of the Pusher newsletter has the following:
We've always loved WebSockets, and since the beginning they have been our primary transport mechanism. While they are still the best way of sending data between applications, we do sometime have to resort to various trickery to negotiate troublesome proxies. By popular demand we are soon going to be bolstering our legacy support by adding HTTP based transport to our existing fallback options.
We have already deployed some provisional endpoints which apply in a set of limited conditions, and we'll be continuing the expansion of this feature over the next few months. If you want to have early access to this as a beta user, please get in touch with support#pusher.com.
In terms of cost:
Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
Have you contacted Pusher support explaining your use case? Discounts may be available.
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
There's a realtime web tech guide which has a good list of realtime web technology solutions (it's on my site and I maintain it). If you want to support IE then a solution which offers HTTP-based fallback is the safest bet.
I would personaly go with socket.io. It supports Internet Explorer 5.5+.
It supports various transports and uses the most-appropriate one to ensure browser compatibility without having special code to work with each browser. Here is the list of transports from the website:
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
You can see the full list of browser support here.
As for BOSH, here is a discussion on BOSH vs Websockets. If you go ahead with BOSH, you will be missing out on Websockets functionality that modern browsers support.
You should check out ScaleDrone as an affordable alternative to Pusher.
My web server is in east coast.
I sent an email from my web server at 1PM PST time which is 4PM Eastern time.
I am resided in west coast and when I see the page, it shows 4PM which is future time for me.
How can I see 1PM, someone in east coast 4PM and so on?
The date is stored in MongoDB which is UTC. I also convert date before displaying:
#Model.DateSent.ToLocalTime().ToString();
This is how I set the time when mail is sent:
DateTime.UtcNow <-- So I am storing date in UTC already
Thanks
There are two parts to your question. The first is the mechanics of localizing a dateTime in C#. Since I'm not a Windows guy, I'll leave that to either someone else to answer or you to look up in the docs, but I'm willing to bet that ToLocalTime() has a friend that takes a TimeZone or a Locale.
The second part, which is more interesting, and something I've had to deal with a few times in the past is how to know what timezone to use. There's no right answer, but there are a few strategies:
The simplest, and perhaps the best, if there's a concept in your system of a user account
is to simply make the Locale a user preference.
If there's no concept of a user account one's always logged into there are a few ways
to go
you could make it a choice that is saved in the session, but that's a bit annoying
to force them to select every time
a better alternative might to be geocode the inbound IP address and set it from
that. There are geocoding apps, databases and services. Most cost, but I know
MaxMind has a free edition that does ok. That will mostly work. The catch is
users coming via some large private network. I live near Philadelphia. My home
network usually geocodes pretty well, though a few services place me in Delaware,
where my ISP is located. But at work, where the whole company goes out through
a single web proxy, I look like I'm in North Dakota.
more reliable, but perhaps more involved, is to grab the browser's timezone
using getTimezoneOffset() in Javascript and push the answer up to the server.
I suppose the other option might be to convert the time locally in the browser,
where the timezone is freely availiable, but that implies that the data is
coming down via AJax or similar and then being updated via JavaScript. Fine if
you're doing a app that is fundimentally Ajax RIA based, just send the data
in UTC or as a time_t. But kind of silly and annoying for a classic web app
that isn't already processing all the data client side.
My first choice would be a user preference. If that's not an option I'd probaly push the timezone from the client. And if that's too involved, go for IP geolocation.
An opinion question: do you think it's safe already to use WebSockets what with the changing protocols? If not, when do you reckon the protocols will be finished?
Thanks!
The protocol isn't really changing much any more. Most of the discussion is around optional extensions and phrasing in the specification. There was no wire protocol change between HyBi-08, 09 and 10 (which is why the handshake version has stayed at '8') and very little change between 08 and the previous several versions. The protocol has also completed last call and been referred to the IESG/IETF so radical changes are not likely unless some serious issue is discovered that throws the protocol back into the HyBi work group for rework.
One of the bigger changes coming soon is for in the HTML API related to binary data support and close events. However, these changes are basically just additive and still backwards compatible with the current API.
Short: I am looking for a very simple (configuration/maintenance wise) solution, that would allow to collect user-feedback/bug-reports from my apps/web-sites over the internet.
Long:
Right now I have very simple web-app written using ASP.NET MVC that receives http-post requests at http://localhost/feedback and saves them as c:\temp\{guid}-feedback.txt. I used UltiDev HttpVpn (BTW it's very cool) to expose this page to the internet without having to put my app in DMZ. I collect following information (through a feedback form in the app, or a web-site's feedback page): user name, e-mail, type of the message (feature request, bug report, comment), application name (hard-coded in the app that sends the feedback), and message-text/comment.
About E-mail:
E-mail is not good enough, since there will be no e-mail client on most of the computers my apps are running at (also, it takes too many clicks to send an e-mail).
About JIRA:
IMHO JIRA is too heavy for what I need. I might be wrong, since I have never installed/configured it myself. Does it have a http-post interface (so I can put my own interface on)?
.NET on Windows solution preferred
FREE is a requirement
To my opinion http://www.useresponse.com is a nice alternative to SaaS services (will be once released on December 2011) you can install on your site and customize up to your satisfaction (both look and functionality).
Commercial, though. Don't think you'll have enough functionality from free scripts (neither support and new features).
Worth checking out FogBugz. I used it many versions ago and it has changed a lot since then.
But it allows you to report app crashes / bugs, etc. through a number of mechanisms (see link for details): http://www.fogcreek.com/FogBUGZ/LearnMore.html?section=NewPlatform#hist_PullCases