命令行应用程序 Web 前端的推荐通信模式
我有一个 Perl 应用程序，它处理来自本地文件系统的文本文件（将其视为过于复杂的 grep）。 我想设计一个 Web 应用程序，允许远程用户通过设置所需的参数来调用 Perl 应用程序。 一旦运行，perl 应用程序和 web 应用程序之间就需要就进程的状态（运行、完成百分比、完成）进行某种通信。 两个进程之间推荐的通信方式是什么？我在考虑数据库表，但我不确定这是一个好主意。
任何建议表示赞赏。
I have a perl app which processes text files from the local filesystem (think about it as an overly-complicated grep).
I want to design a webapp which allows remote users to invoke the perl app by setting the required parameters.
Once it's running it would be desirable some sort of communication between the perl app and the webapp about the status of the process (running, % done, finished).
Which would be a recommended way of communication between the two processes? I was thinking in a database table, but I'm not really sure it's a good idea.
any suggestions are appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Stackers，请继续编辑此答案以添加代码示例或链接。
DrNoone，我想到了两种方法。
回调
您的 greppy 应用程序需要提供一个回调函数来返回状态，并由 Web 应用程序定期调用。
活动
如果您已经在使用 Web 服务器/应用程序框架，该框架公开了可从外部应用程序使用的事件循环（在 Perl 领域中不太可能），那么这是有意义的。 greppy 应用程序在状态更改时触发事件，Web 应用程序附加/侦听这些事件并采取相应的操作。
对于您想象的 IPC，普通数据库不太合适。相反，请查看消息队列。为了获得良好的互操作性，请选择符合 AMPQ 的实施。
Stackers, go ahead and edit this answer to add code examples or links to them.
DrNoone, two approaches come to mind.
callback
Your greppy app needs to offer a callback function that returns the status and which is periodically called by the Web app.
event
This makes sense if you are already using a Web server/app framework which exposes an event loop usable from external applications (rather unlikely in Perl land). The greppy app fires events on status changes and the Web app attaches/listens to them and acts accordingly.
For IPC as you envision it, a plain database is not so suitable. Look into message queues instead. For great interop, pick AMPQ compliant implementation.
如果您使用
open($handle, "cmd |")运行该过程，您可以实时读取结果，并在响应打开时将其直接打印到 STDOUT。这可能是最简单的方法。If you run the process using
open($handle, "cmd |")you can read the results in real time and print them straight to STDOUT while your response is open. That's probably the simplest approach.