I’m very new to gwt developing and I would like to know, if it is possible to change client information’s from another client. I would like to do following;
Person A adds a new car to a list, this modification should also add automatically to another client (website). Is that possible with gwt? Right now, I’m just having the idea to use a solution with a SQL database. Is there a way to connect two websites?
Greet
There is no way to do that directly from client to client.
You will have to implement it via a backend (not necessarily a SQL Server).
Client A sends the modifications/data to the backend.
In order for Client B to see the update you can rely on two different techniques:
Pull by polling via a Timer (easy to implement)
Push either by Websockets or Comet (check out atmosphere project)
Push via event based service (check out gwteventservice project)
Related
Creating a user, adding some record to collection in the DB, updating some stuff, etc..
All of these we regularly do with HTTP requests against REST api.
Think about making Event bus as server instead of REST api.
In that method, create user will be an event name: "CreateUser" instead of REST api endpoint: POST /users.
In reflect to any action done in the event bus, it will re-emit a following event telling to any body needed to know about, that the event was done.
If for example someone viewing the vehicles collection and another user just edit one of the columns or add a new vehicle instance, it will be reflected immediately to who views it online.
My question is if there attitudes like I mentioned above, if there some formally names for it, if it a good practice, if you know someone who regularly uses it, a framework or something etc. Does the socket.io server can handle and behave like http server in high workloads?
You can use websockets for this; they provide a bidirectional channel between client and server to send messages across. You will have to catch and parse the messages on each end yourself, as there is no additional protocol on top of them.
They don't hold state, so there is no knowledge of who is looking at what, or who got what. You could send the same update message to all connected clients and leave it to the client to use it or not.
You would have to reprogram your client code and the API endpoints, because it's a different way of doing things, and it can also do server push.
I have no idea about frameworks though, as I always use them without one. Websockets are fast, but server behaviour at high workloads depends on implementation, and I only have experience with the websocket server I wrote myself. I suppose the performance of the socket.io can easily be googled.
This is what I want
A user(bot) that always shows status Online
When a message comes for the user, I will hit a webhook associated with the user
The response from the webhook request will be sent as reply to the sender
This user will be able to intercept any message (let's say for profanity moderation)
This user will be able to send message to anyone (let's say broadcast)
This user will come in every users roster as default(like echo bot of skype)
I can't seem to find any resource on how to achieve this. I've found a way to intercept the incoming packet in openfire but I don't see any easy way to do this with MongooseIM. I haven't started diving deep into the source code yet, still looking for a way to do this without touching the source code and locking myself to a specific version of MongooseIM.
Disclaimer: I'm on the MongooseIM core team.
There are multiple ways this could be achieved. The easiest way to achieve this depends on your familiarity with Erlang, the programming language MongooseIM is written in.
You won't need any Erlang to use the event pusher module with its HTTP backend and the default settings, but you'd need some Erlang to control what messages get forwarded to the HTTP service or to make more complex setups. To send messages back, you'd either need to use the MongooseIM REST API or connect as an ordinary XMPP client to the server using one of the many XMPP libs available out there. This is probably the best approach to achieve your goal.
You can skip using the event pusher and just connect your bot as an XMPP client written in any language whatsoever. The bot might have your business logic within or can forward messages it gets to the HTTP service.
If you're comfortable working in Erlang, then the mechanism to extend the server is called Hooks and handlers and is described in the official MongooseIM documentation. This requires writing code in Erlang and building from source, but does not necessarily require modifying upstream MongooseIM code.
You could use the XMPP component protocol, which allows to extend the functionality of an XMPP server, yet structure it as multiple services. The components may be written in any technology you want and the most popular XMPP libraries should support the component protocol out of the box.
Depending on your choice from the above list and the language and environment you prefer, you might have to pick an XMPP library to use. There are XMPP libs available for iOS (ObjC and Swift), Android (Java and Kotlin), Python, JavaScript, C, and even some emerging ones for Rust, Dart and possibly more.
I need some advice on how propagating server-side changes of entities to the client is best handled with GWT's RequestFactory.
Let us assume we have two EntityProxies, a PersonProxy and a PersonListProxy (which has a getter for a List). Assume that the client has fetched a PersonList and a Person from the server.
In case the client is editing one of these proxies and firing a request, the machinery of RequestFactory (if I have understood the principles correctly) will fire an EntityProxyChange event if it detects changes done by server code (so that the client can update its display of the entities, for example).
Now assume that the server is changing its entities outside of a request by this client (e.g. due to another client calling the server) so that this client would see another version if it fetched the Person or the PersonList again.
My question is what is the best way inside the RequestFactory framework to tell the client of the changes (and to reuse as much of the machinery as possible)? We can assume that I have a way to send simple messages from the server to the client (e.g. Google App Engine's channel API or server-sent events).
One idea could be that the server sends over this channel a message telling that a Person or a PersonList with a specific id has changed. The client code handling the receipt of these messages could then use RequestFactory to re-fetch (e.g. find) the entity. This change should then be propagated to other parts of the client by an EntityProxyChange event.
Is this the way to go? (And in case that the client already has the current version of the entity, e.g. because the server was dumb and notified the client of changes the client itself made, would the triggered re-fetch just transport a few bits of metadata and not the whole entity again?)
ADDED:
Thinking a bit more about it, I wonder how EntityProxyId's can be generated for the server-sent event channel. When an entity on the server changes, the server only has the server id. It can then send it to the client, of course, but the client only knows of EntityProxyId's. Of course, I could add a getId() (in addition to getStableId()) to each EntityProxy, but it looks as if this would add redundant data to every server response.
Well, I realize that my post isn't precise answer to your question, but it's just my experience.
In fact, there is just a question how to deliver data from server to client.
I faced with some task couple years ago, and found for yourself an approach that make my life easier. To explain it, I want to specify my reasons:
You have to have full data delivery by requesting it from client - it's straight, natural way to requesting data;
You don't want to create and support 2 different models of full data delivery: one by requesting from client and second by pushing from server;
But you need to inform client about some changes on server side;
So, now I'm building my architecture using following approach:
Build full classical client-server API for data delivery - so you can load and refresh your application in natural way even if your pushing functionality is blocked or broken.
Define key information that may be changed on server side and should be delivered to client via push mechanism.
Create small push message construct(s) that will deliver to client just a notification about changes - no any valuable data should be delivered this way - just keys which data was changed.
All that is needed to do on client when it receives such notification is just to get/refresh data from server in natural client-server way that is already supported.
Server logic shouldn't bother client side by huge amount of notifications - sometimes is more effective do not deliver changes, but just refresh everything.
Hope this helps.
I am getting some difficulties with comet on the server
First, I am working with the default configuration of the gwt hosted
mode(i.e. using jetty), do i need to make any change to enable comet
Now, on the server what I want is a client will send a request and
then he will be enrolled in a so-called group. Whenever, any change
happens to all group, all client connected to that group are made
aware.
Can someone help with this??
Check out http://code.google.com/p/gwt-comet/wiki/GettingStarted
I'm currently looking into XMPP and I would like to know if there is a way to create dynamic XMPP rosters. I want the contact list of any user be automatically generated by the server / component / plugin.
Can components access and modify rosters?
I know that some servers (like OpenFire) use an external database to store these information but if I modify the database, I don't think the users will be notified in realtime.
Are some people already doing that or do you have an idea how to create it?
Thank you for your time.
In most XMPP servers this is called "shared roster groups".
I can't comment on Openfire in particular because I haven't used it for a long time, but I don't think I know of a server currently in which external roster changes are instantly transmitted to clients. Usually the client will simply pick up the new roster when it next logs in.
It would be possible to push the updates instantly to clients using what XMPP calls "roster pushes". This would require quite some work on the server though to identify what the changes are between what each client knows the roster to be, and what the new roster is, and then transmit just the changes.
If you really need this then a server plugin would probably be the way to go, or pester your server developers for the feature (I know that as a Prosody developer I've already been pestered, and this is something I'm planning to work on).
As for whether components can access users' rosters - this is dependent upon the server implementation and configuration.