I was using a jquery plugin to talk with bosh:
https://github.com/maxpowel/jQuery-XMPP-plugin
I read that i can use strophe to send data in stream mode, in order to save bandwidth.
What i need to have:
One normal channel where i exchange commands between chat computer users
Several channels to send not formatted data, but with the smallest amount of information, because the time of each message can round between 100ms
I've made a graph for better understanding.
How to do this with Strophe?
Second question is that i read about this json plugin for strophe http://code.google.com/p/prosody-modules/wiki/mod_json_streams .
Do you have already tried this? Is it stable and gives really a good win in bandwidth?
Thanks for your answer.
Best Regards,
Regarding your second question, thats just an april fool joke (note the date it was published), and also, the XEP 0295 that the page references make that clear:
NOTICE: This document is Humorous. It MAY provide amusement but SHOULD
NOT be taken seriously.
Related
I am creating a webpage in ReactJS for post feed (with texts, images, videos) just like Reddit with infinite scrolling. I have created a single post component which will be provided with the required data. I am fetching the multiple posts from MySQL with axios. Also, I have implemented redux store in my project.
I have also added post voting. Currently, I am storing all the posts from db in redux store. If user upvotes or downvotes, that change will be in redux store as well as in database, and web-page is re-rendering the element at ease.
Is it feasible to use redux-store for this, as the data will be increased soon, maybe in millions and more ?
I previously used useState hook to store all the data. But with that I had issue of dynamic re-rendering, as I had to set state every time user votes.
If anyone has any efficient way, please help out.
Seems that this question goes far beyond just one topic. Let's break it down to the main pieces:
Client state. You say that you are currently using redux to store posts and update the number of upvotes as it changes. The thing is that this state is not actually a state in your case(or at least most of it). This is a common misconception to treat whatever data that is coming from API a state. In most cases it's not a state, it's a cache. And you need a tool that makes work with cache easier. I would suggest trying something like react-query or swr. This way you will avoid a lot of boilerplate code and hand off server data cache management to a library.
Infinite scrolling. There are a few things to consider here. First, you need to figure out how you are going to detect when to preload more posts. You can do it by using the IntersectionObserver. Or you can use some fance library from NPM that does it for you. Second, if you aim for millions of records, you need to think about virtualization. In a nutshell, it removes elements that are outside of the viewport from the DOM so browsers don't eat up all memory and die after some time of doomscrolling(that would be a nice feature tho). This article would be a good starting point: https://levelup.gitconnected.com/how-to-render-your-lists-faster-with-react-virtualization-5e327588c910.
Data source. You say that you are storing all posts in database but don't mention any API layer. If you are shooting for millions and this is not a project for just practicing your skills, I would suggest having an API between the client app and database. Here are some good questions where you can find out why it is not the best idea to connect to database directly from client: one, two.
What is the term for a webhook that makes another set of webhooks?
A recent kludge (Unbounce, Zapier, Twilio) only allows me one webhook (i.e. custom one from Zapier)
https://zapier.com/zapbook/twilio/unbounce/
Eventually, however, I will need to generate multiple actions on different (customzed) platforms, so I was hoping to have a hook that goes to one place and then from there, vector off hooks to my other beta site (including Zapier).
Any suggestions would be greatly appreciated.
I note your question was about unbounce, but included Zapier. I'm assuming from this that you were looking to use Zapier as the "one place" (i.e in the middle)"
Now I don't know Zapier, but came across your question looking along the same lines. The terms I'm familiar with on this are "one-to-many", "fan-out" or "publish/subscribe" communication styles - but aware that these may be a bit old school in Web 2.0 world.
In my search I came across a Zapier Support post on Multiple Zaps.
In summary, looks like you may be able to achive this using a "Zapier Delay Trigger zap"
The possible downside (depending on delivery time requirements) is that the delivery of onward webhooks would be complete "...within 5-15 minutes". This doesn't quite fit my requirement, by may fit yours.
Edit: A quick search on "fan-out" term also found this on using Zapier Queue. Again,as it's queuing I suspect there may be a delay in onward processing.
Edit2: Following email to Zapier support - situation is still as per links i.e.time delay, but "...in your zap you can define the length of the delay to minimize the lag. This case you shouldn't have any problem setting a 1 minute delay since there's no need for it to be any longer, which can help you get a lot closer to 'near real time'."
Edit3: Further info from Zapier support - apparently if you configure two Webhook-Webhook Zaps you can fire them both with one URL as "https://zapier.com/hooks/catch/xxhook1,xyhook2" - appears to fire both zaps pretty immediately.
Edit4: One thing to watch with the multi-zap approach (as Edit3) is that if one send to target fails then you can replay manually (via Zapier site and paying customer) - there's no ability (currently) to manage automatic retrying (not sure if there's any ability to monitor this event).
I've written a little program that reads and converts my local playlists from the iTunes xml (some more background on my blog: Reading the Playlists from the iTunes Library XML).
Now I want to do something similar with the playlists that are stored on my iPod (in my case, a 2nd generation nano; please no iPhone anwers - I'm already envious ;-)). Any legal way to do this?
OS 3.0 lets you get at the playlist.
Checkout MediaPlayer.h.
Ah, wait. Nano? No, I don't think so. I assumed you meant ipod touch.
It's been a long time since I've dealt with that particular brand of iPods, but if memory serves; if you enable disk mode (if possible), all the info on the iPod will be accessible through a hidden folder on the Volume that shows up in Finder.
Where on that volume the information is I couldn't tell you, but it's probably in there somewhere; most likely in the binary property list format; so the data might take some massaging, but a simple trip through an appropriately factored command line tool should yield the info, or the info in it's XML incarnation.
If, however, the Nano doesn't allow use as a hard disk, I'm afraid there's not likely to be a whole lot to be done for it.
The only way that seems to work is to access the iPod through iTunes. iTunes offers an "older type" COM-based interface (?) called iTunesLib. You can register with Apple to get some documentation, but there is a decent description in Dan Crevier's Blog on MSDN.
There must be some other ways though, as there are some alternatives to iTunes that also allow to transfer music to iPods etc. Ideas, anyone? ;-)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a web based application which uses a JSON over HTTP based API to communicate between the server and the client. The goal being that multiple clients can be developed with different goals (online web client, offline desktop client, or third party created) using the same online data to be shared through this web service.
Right now the communication between the client and server is sent via POST only through a system that works well. I read quite a bit of information about REST and being RESTful with HTTP using PUT, GET, POST, and DELETE. I could separate my API into these different categories, but it means more code and some changes to the API.
My question is: how important is it for a HTTP based API be RESTful? Is it a recommendation, an option, or a near necessity?
Thanks in advance.
As a die-hard RESTafarian I'd say use HTTP (the REST protocol in question) to its full extent. Why? Well, I'll show you two snippets from an email exchange I had yesterday with a good friend of mine who's seriously clever (and used to be a professor of IT, still lectures, still kicks ass wherever he goes) ;
Yesterday I passed an important
milestone for my mappodrhom
application: I can now launch
long-running background computations
into a worker pool. When they finish,
the workers POST back their results
directly into the REST resources.
Which triggers more background
processing, all controlled by a
dependency graph.
And the interesting aspect is that
this RESTful backgrounding is
actually independent from my
particular application. But I am
currently too tired to completely
grasp the consequences :-)
The consequences in question are huge (it's a REST framework with lots of little stacks and events and services and apps, all with their own discoverable URIs, all with the same unified interface), and in terms of extensibility and scalability it is simply unmatched in its simplicity. If your application is a dinky little thing that will never travel places or meet hot chicks, yeah maybe you don't need it. But then, I've said the same, and all of a sudden found myself on a train to Paris with a cute girl that is a secret spy for the Russians, and well, one thing led to another...
Here's my reply, with some of my own experiences ;
I think this sounds (pardon my French)
f***ing awesome! I'm experiencing
similar things with my own REST stuff,
where because the middle layer is so
thin and transparent, I can just
extend things the way I need them
without worrying too much about the
infra-structure. It's such a freedom,
such a kick-ass cool thing that my
brain is about explode, and a
worrisome curiosity to why more aren't
doing it?
In short, doing REST only half-way is just like not really doing it at all. You're just shifting your stuff over a different pipeline, missing out on a simplified API into a state-machine, semantics- and implementation decoupling at the core, working with the principles that built the net (and hence I'd say you've got rather proven ideas behind you), the unified interface, and having URIs as part of your modeling.
I know it's popular to say that you can pick and choose, that it's all just options. It's not. REST only makes sense by using it fully, but as to convincing you to actually stretch your brain a bit further and do something clever, I can only dare you to cut through the FUD (that it's all about RPC, only GET and POST necessary, you don't need it all, equivalent to JSON, SOAP and other ilk, etc.), and be smarter about how you make applications. Yeah, I dare you all!
Unless you are going to take advantage of hypermedia then I wouldn't bother trying to conform to the REST constraints. Hypermedia is the piece of the puzzle that makes the system greater than the sum of its parts.
You are free to pick and choose which of the REST constraints you want to respect in your architecture, just note that to be able to call the end result RESTful, the only optional constraint is "code-download".
It's an option amongst several for exposing a web application as a web service with a well-defined API. Other options include:
No API - The application has no real way to be used as a component in other distributed systems
SOAP - An XML format for defining API remote calls
JSON - A compact format for information exchange that can be built on to create a custom API format (or used to build a REST system if you wanted)
Many other forms of remote procedure calls and information exchange mediums.
REST has a nice ideal behind it, but that doesn't mean you have to provide a REST API for your application. If the gain isn't worth the extra effort, don't bother.
It is a recommendation. I am glad you did not go into how RESTful you need to go into as there is something called Hi-Rest and Lo-REST. You can get more information from googling. Some industry veterans I know do not much care about this, but I do find staying as close to html and http will help you in the long run and simplifies many things.
I would submit that it's a nice to have but not a must. In my experience adding this architecture increases the scope and complexity of the project, but it does add a degree of elegance to the whole. I would say if you've got the time and budget on the project, go for it, if not don't worry about it.
One (of the many) things to consider with service API's is the ease in which they can be consumed by your end user. REST is gaining a very strong tooling presence.
By far the largest dev group out there is the .NET dev group, and with ADO.NET for services (Astoria) consuming REST using Linq is very simple and very elegant.
We have a customer who wants to go through their CRM database and somehow determine phone numbers which are valid, without actually having someone sit there and try calling them all.
Is there any way to do something akin to a "ping" on a phone number (including landlines)?
You will need to go through a third party. I have used Melissa data for address verification with good success, they also offer phone verification, but I have not used it
http://www.melissadata.com/listservices/resphoneverify.htm
If getting a 100% correct phone number is crucial, I'd look into a service which would actually call the number, give a verification code and make the user confirm that code with the site. It is a PIA from the users perspective, but that is the most complete route you can take. Doing a quick little googling came up with this site, http://www.phoneconfirm.com which seems to do what I mentioned. I am sure there are others though.
If you can't/don't want to go through a third party, I can't imagine writing something like this yourself would be impossible. Scaling it would be the biggest issue.
could always go with the good ole war dialer
I believe a CTI system using ISDN calling based service can quickly return a status code that the number is either valid/invalid before the destination begins to ring.
One vendor is Katalina systems, their product is called VoiceGuide and they have a dialling out module that may give you what you want. see www.voiceguide.com.
Just export the calling list to the dialler (csv file) and review the call status after processing.
If the list is very large, it may justify purchasing a system to do this. The rate of calling depends upon the number of lines installed/availble. You might require some custom modifications to abort the call after obtaining the status. Katalina should be able to help. I am not sure if VoIP trunks can give you full access to the line status.
I once did something like that. Yeah, for telemarketers. And yeah, it haunts my conscience to this day.
It was based on a module called app_amd.c (Answering Machine Detection) which was a third party add-on for Asterisk and, AFAIK, can be found in their main tree now. With an E1/T1, you can also distinguish between bad numbers, busy, and many other status codes. Look that up, it may help.