From ejabberd's webpage, I learn that one can extend ejabberd's functionality by writing modules using hooks/events etc. However, all the examples are in erlang, which I don't really know how to use. Of course, I can go learn it, but my question is whether I can avoid it altogether. Namely, is the following possible:
I write some REST server (using something else, like node.js/golang/python whatever), and then somehow hook it into ejabberd's event system.
What is the best way to go about this? Any link to a code example/tutorial would be great!
Thanks a lot.
It depends on what kind of feature you want to write. For some modules, you may want to use the internal API. Please note that you can use Erlang or Elixir, which is much easier. For example, here is how to write an Elixir module:
https://blog.process-one.net/elixir-sips-ejabberd-with-elixir-part-1/
The other approach is to use the Jabber XMPP component protocol. It is more limited but allow you to write XMPP components in any languages. Here is a description of Jabber component protocol, supported by ejabberd:
http://xmpp.org/extensions/xep-0114.html
Related
Is there any tool for viewing registered types in CORBA Trading Service, and maybe, for making some simple queries for objects?
I am using TAO, if it matters.
Not that I know off. Maybe you can write your own and contribute it back to TAO. Maybe consider a scripting language for a client, like Ruby with the R2CORBA implementation which is interoperable with TAO
I do realize that this question seems very well known, but since I don't have a lot of experience using SOAP web services and as far as I could find this is not very common topic on iOS and especially OS X, I will ask it again.
I have tried wsdl2objc and sudzobjc and both solutions seem to be pretty much complex. I have a feeling that there is a lot of overhead, too, especially with all those types defined and pointers used.
If I compare this to simply using standard Cocoa classes NSURLConnection and NSXMLParser like in this example:
http://abhicodehelp.blogspot.com/2010/12/handling-soap-with-iphone.html
like when using RESTful web services, it feels like overkill...
I would appreciate anybody to give me a hint, why this more complete approach is better and wouldn't it be better to use any other C or C++ libraries that at least by first look seem much lighter and easier to use?
The problem of SOAP is that it's really, really bloated! It's called Simple Object Access Protocoll but it's anything but simple. It's based on XML and (mis)uses all of it's complexity with WSDL and XMLSchemes and all that stuff. I started working with SOAP in my Java time as it was just invented. And we had OutOfMemoryExceptions more than once because of the size of the XML message.
That said: calling SOAP services with Objective-C will be as complicated as it is with Java or any other language. The problem is you need to create rather (or even very) complex XML structures to call a service. I knew wsdl2java and that helped a bit but it created a whole bunch of classes and abstractions and stuff.
I understand the idea behind WSDL and all the XMLSchema stuff that's used in SOAP. It's to create a service and it's specification so that others can call it without problems. But I don't think that's the way to do it.
If you've got the choice take REST! REST is the real "Simple Object Access Protocoll" as it really is simple. And it can also use XML as a message format, even though you wouldn't want to. REST with JSON is the way to go. You only need to understand HTTP to understand REST, IMHO.
I'm working on Windows XP/Delphi 7. I need to add some procedures (or functions) inside a program that is running, and I do not want to re-compile it once again after I finished it.
I just have a host application with 5 functions to send different types of alarms, but there are other new alarm types, so I have to do new functions to send those alarms, but I should not re-build the host application. I have a class named TAlarmManager that it's invoked calling those functions.
Maybe a plugin?? OK, but how can I "insert" new functions??? Tutorial, manual, book, etc.. for learning about this, or any advice on how to do this???
I have studied plugins (I'm totally new on this theme), but no one "talks" about adding functions to a host application. It seems to me that plugins add functionality from itself, I mean, they have been developed with self code to do something, not to "add" code to the host application... How can I do this??
For the technical side: How does the Delphi IDE do it? That would be the first place for me to look.
To understand plugins, you must understand that you can't add new functions. You could but since the old code doesn't know how to call it, they wouldn't be called.
So what you do is you add a "register" or "start" function to your plugin. That start function gets a data structure as parameter which it can examine or extend. In your case, that would be the list of alarms. Alarms always work the same (my guess), so it can add additional alarms.
The main code will then, after registering all plugins, just walk over the list of alarms and invoke the standard alarm function on each of them. It no longer cares where each alarm comes from and what it really does.
The key here: You need to define an interface which both sides subscribe to. The main code calls the interface functions and your plugin code implements them.
Another option available is to use a scripting component to your project. One which works quite well is PascalScript. This would allow you to load external scripts after the fact and then run them as needed to interact with your application. As Aaron suggested you will also need to still provide an interface of some sort for your script to interact with your application.
See also Plugins system for Delphi application - bpl vs dll? here on Stackoverflow.
I'm not quite sure what you mean by "alarms", so I'm making a couple of assumptions.
1) If you don't need additional code for the alarms, I would try to make them data driven. Keep the different kinds of alarms in a database or configuration file, which makes it easy to update applications in the field without recompiling or reinstalling.
2) If you need special code for each alarm, you could use run time packages as plug-ins for your application. Search for Delphi runtime packages to get some ideas and tutorials. Here are a couple of links I found:
http://delphi.wikia.com/wiki/Creating_Packages
http://delphi.about.com/od/objectpascalide/a/bpl_vs_dll.htm
3) Scripting, as skamradt already mentioned. If it makes sense for your application, this could also let your customers write their own add-on functionality without requiring a recompile on your part.
You almost definitely want to use Pascalscript, as skamradt suggests. You should start here, and seriously consider this option. There are many possibilities that come out of being able to serialize live code as text. The only downside is possibly speed of execution, but that may not matter for your application domain. I would have upvoted skamradt, but I don't have enough reputation to upvote :)
Some time ago I was looking at a situation sort of like what you're describing.
My answer was .DLLs. I put the variable code in a .DLL that was dynamically loaded, the name specified in a configuration file. I passed in a record containing everything I knew about the situation.
In my case there was only a success/fail return and no screen output, this worked quite well. (It was commanding a piece of machinery.)
This sounds like a place where a scripting language or "Domain Specific Language" may make sense. There are several approaches to this:
Implement alarm functions in VBscript (.vbs files written in notepad) that accesses your Delphi code via COM API. Using the COM API gives you access to a large range of programming tools for writing functions, including Delphi. This is the most clumsy solution, but easiest to do. It may also be a benefit to your sales process, and it is always good to think about how to sell things.
Implement your own function language in Delphi. This way you can make it so easy, that your endusers can write their own alarm functions. If you do it as an expression evaluator, you can write an alarm as 2*T1>T2. There are several expression evaluators out there, and you can also write your own if they don't match your needs.
Use a predefined programming language inside your Delphi application, for instance, "Pascal Script", see http://www.remobjects.com/ps.aspx
You should take a look at PaxCompiler, like PascalScript it allows to load scripts, but you can even precompile them before for more performance. Look at the demos section for the solution of your problem.
As a side note, the web page really looks bad, but the package is really powerful and stable.
I think that the scripting solution it's good for this situation.
There are many scripting packages that you can evaluate:
Context Scripting Suite
Fast Script
RemObjects Pascal Script
TMS Scripter Studio
paxScript
Other packages that you can find on Torry, DSP, VClComponents,...
Regards.
I am building a site that has a lot in common with a person-on-person chess site. I was thinking of using Rails for the front-end(User Registration, Navigation, etc) and something like Scala or Erlang for the engine(Game state and maybe AI). I was wondering -
Is this a good situation to use that type of design?
How exactly would be best to divide up the functionality between the components?
How would they best communicate with each other?
I'm open to any technologies or ideas.
If you're using Rails for the front-end, why not use Ruby?
If you like the idea of using Scala, why not use Lift for the front-end?
Chess is turn-based, and has a very simple board that can be handled with HTML and/or Javascript enhancements - so the basic model flows quite nicely with existing web frameworks.
With this in mind, Rails is a great choice for creating a web-based application. Rails is not just limited to crud applications, and in fact I think can write your entire app in Rails/Ruby - you don't really need to have an external engine.
Within the browser space, polling for turn updates can be done using XMLHttpRequest and a database can maintain the current game and turn state.
Looks like a simple Lift application to me. I'm not experienced with Lift, mind you, but it doesn't seem particularly more complex than the chat application that is so often demoed.
I would start by reading http://www.htdp.org/ How to Design Programs. The questions you have asked are very broad and difficult to answer without prefixing statements with "I believe that..."
I would code it in clojure (but that's just me).
I'm currently developing a suite of online games, using Scala. It's been absolutely fantastic - my game logic is much easier to get right with the static typing etc, and dealing with server/client protocol (a flash client, in this case) is made simpler via the use of Google Protocol Buffers.
If you're a huge fan of RoR, by all means use that. I think most statically typed languages are terrible to program websites in (Java, I'm looking at you here), but Scala gets rid of 90% of the pain, and gives even more safety.
Of course, it might not be your cup of tea. But I'd try just doing the entire thing in Scala, and adding another layer if that doesn't quite do it for you.
For question 1 Yes
And for 2 and 3 you need to give more information in order to get an answer that could help you.
Now I'm doing something like you but for the front end I'm going to use Grails. The reason are very simple: I like Grails, Scala and I want to mix them :)
I need a few of my related applications to communicate to each other (exchange data and initiate actions). Requirements are without packages and no sockets. So I guess that leaves named pipes, WM_CopyData (like Skype does it) and command parameters. What are your best practices?
You probably have a couple of options.
Beyond what you already have:
DDE
Memory Mapped Files (MMF)
MailSlots
I would probably go with either the Pipes or the MMF.
There are a couple of free MMF components that you can download,
Deborah Pate has a set of freeware classes you can use.
MapFiles.zip
Check for MailSlots on Torry's site.
The final solution might be dependent on the amount, size and frequency of the data transfers that decide which option you choose.
I would advise to use COM in this situation. (Attention: not COM+, not ActiveX, not OLE; COM, just COM.)
Since Delphi 7 (or an earlier version, I'm not sure), this is easily done by adding a Type Library to the project, and an Automation object.
Advantages are it's pretty widely supported, both within Delphi (the Type Library Editor has everything you need and updates your code, and COM internals and registering are catered for from the ComServ unit), and outside of Delphi (I use it in a number of project to interact with all sorts of applications: C++ projects, Word and Excel documents using VBA, oldskool ASP...).
An only disadvantage I encountered may be threading issues, in normal applications, a plain CoInitialize(nil); at application startup will do, in more complex applications, you need to think about 'threading apartments' or use free threading and do your own locking. (Which in some cases you've been doing already.)
Another alternative which is dirt simple to implement is to use the database to pass information.
Not overly elegant, and it does use a lot of overhead, but if your application is already data-aware (ie has a database as part of it), then using a table or two to pass information is pretty easy.
You could use simple files: One side writes to it, the other reads. If you need two way communication, just use two files, one for each direction.
Of course this is not really high performance.
Another vote from me for named pipes, for the data exchange. I like them slightly more than mmap files, since the win32 pipe APIs give you some nice choices out of the box: sync/async, byte stream vs message packets, simple ReadFile/WriteFile calls. All of which you could do yourself with mmaps... but pipes are already there...
And you can control access with security attributes -- which isn't an option with WM_CopyData. This might not be an issue immediately... but can be handy to have the option, even if you don't care who sends your app messages. For me, this was helpful when Vista came along, and suddenly user apps ran in a separate session to my service. Was good that tweaking the security attributes was the only thing needed to get things working again.
For "initiating actions", you might be able to get away with something as easy as some named Events, and not worry about sending messages at all? The interested parties simply wait for it to be signalled.
Personally, I'd avoid COM unless you have to specifically support COM-based clients.
Do not use COM, too much overhead (variants) and you must register you .dll or .exe (and it gives a lot of weird installation + update problems).
I should go for MMF, I use this for communication with Windows Services.
I use the following TGpMessageQueueReader and writer for this:
http://17slon.com/gp/gp/gpsync.htm
If you want to pass data, call functions etc then use COM, however if there are lots of calls be aware that COM is slow. Also you might have to register the application with "xxx.exe /Regserver", before it will work.
Is'nt this the sort of this that RemObjects is good at?
Bri