From: Fredrik T. <ft...@it...> - 2005-05-16 22:35:46
|
Hi I'm looking at using Yaws to write a new web interface for the Yxa SIP server/stack. The .yaws functionality seems to be what I need to write a web interface that is easy to maintain. My problem now is that I need to communicate with my nodes running the Yxa applications from the code in the .yaws files. Using the Erlang 'rpc' module to do this requires me to 1) have a -name for the yaws node, as opposed to an -sname 2) run -proto_dist inet_ssl (plus using a .boot file, and supplying a bunch of parameters saying what certs to use etc), since the Yxa nodes use SSL for Erlang distribution This is doable, but the patch is not what I would call 'clean' so I have little hope of it being accepted unless there is popular demand for this kind of thing. I see only one two alternatives to this approach : 1) Run Yaws in embedded mode from within my applications. I would prefer not to, since I don't want to re-invent the wheel with regards to Yaws configuration management. 2) Talk to my applications using a TCP socket. I would like to avoid this to not have to re-invent RPC and the necessary authentication of it. Have I missed some other way of using Yaws to write a web interface for another (Erlang) application? /Fredrik |
From: Michael M. <ya...@au...> - 2005-05-17 06:35:54
|
On Mon, May 16, 2005 at 05:02:33PM +0200, Fredrik Thulin wrote: > Hi <znip> > > I see only one two alternatives to this approach : > > 1) Run Yaws in embedded mode from within my applications. I would > prefer not to, since I don't want to re-invent the wheel with > regards to Yaws configuration management. > 2) Talk to my applications using a TCP socket. I would like to avoid > this to not have to re-invent RPC and the necessary authentication > of it. > > Have I missed some other way of using Yaws to write a web interface for > another (Erlang) application? > > /Fredrik ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I presently have a simple web interface that shows appmod versions thusly... <erl> out(A) -> [ { ehtml, [ {p, [], dbexp:getRevResponse()} ] } , { ehtml, [ {p, [], expmaster:getRevResponse()} ] } , { ehtml, [ {p, [], filewatch:getRevResponse()} ] } , { ehtml, [ {p, [], mxml:getRevResponse()} ] } , { ehtml, [ {p, [], odbcsrv:getRevResponse()} ] } ]. </erl> I am planning on making a control application that would send control messages to the application. The control application will probably be mapped as an appmod. Perhaps something like that would work for you? ~Michael |
From: Fredrik T. <ft...@it...> - 2005-05-17 07:18:04
|
On Tuesday 17 May 2005 08.35, Michael McDaniel wrote: ... >^^^^^^ I presently have a simple web interface that shows appmod > versions thusly... > > <erl> > > out(A) -> > [ > { ehtml, [ {p, [], dbexp:getRevResponse()} ] } , > { ehtml, [ {p, [], expmaster:getRevResponse()} ] } , > { ehtml, [ {p, [], filewatch:getRevResponse()} ] } , > { ehtml, [ {p, [], mxml:getRevResponse()} ] } , > { ehtml, [ {p, [], odbcsrv:getRevResponse()} ] } > ]. > > </erl> > > I am planning on making a control application that would send > control messages to the application. The control application > will probably be mapped as an appmod. > > Perhaps something like that would work for you? My problem is not to execute functions in my .beam files (that's just a matter of providing the right -pa argument to the 'yaws' startup script), it is to get distributed Erlang running to communicate with my other _running_ nodes. I think I need to do something like this : <erl> out(A) -> T = rpc:call('inc...@la...', transaction_layer, debug_show_transactions, []), Output = io_lib:format("Ongoing transactions : ~p", [T]), {ehtml, [Output]}. </erl> This approach actually works, it just requires me to do lots of changes to the 'yaws' startup script to start Erlang with -name (instead of -sname) and -prodo_dist inet_ssl etc. I would like to avoid having to maintain private patches for such a thing by finding a way to solve my problem that the Yaws community likes, so that I can make patches that have a chance of being merged into the official distribution. Perhaps there is another solution already at hand, which I just don't realize. /Fredrik |
From: Torbjorn T. <to...@no...> - 2005-05-17 10:27:19
|
Fredrik Thulin wrote: > On Tuesday 17 May 2005 08.35, Michael McDaniel wrote: > ... > >>^^^^^^ I presently have a simple web interface that shows appmod >>versions thusly... >> >><erl> >> >>out(A) -> >> [ >> { ehtml, [ {p, [], dbexp:getRevResponse()} ] } , >> { ehtml, [ {p, [], expmaster:getRevResponse()} ] } , >> { ehtml, [ {p, [], filewatch:getRevResponse()} ] } , >> { ehtml, [ {p, [], mxml:getRevResponse()} ] } , >> { ehtml, [ {p, [], odbcsrv:getRevResponse()} ] } >> ]. >> >></erl> >> >>I am planning on making a control application that would send >>control messages to the application. The control application >>will probably be mapped as an appmod. >> >>Perhaps something like that would work for you? > > > My problem is not to execute functions in my .beam files (that's just a > matter of providing the right -pa argument to the 'yaws' startup > script), it is to get distributed Erlang running to communicate with my > other _running_ nodes. > > I think I need to do something like this : > > <erl> > > out(A) -> > T = rpc:call('inc...@la...', > transaction_layer, debug_show_transactions, []), > Output = io_lib:format("Ongoing transactions : ~p", [T]), > {ehtml, [Output]}. > > </erl> > > This approach actually works, it just requires me to do lots of changes > to the 'yaws' startup script to start Erlang with -name (instead of > -sname) and -prodo_dist inet_ssl etc. I would like to avoid having to But why not add the -name switch to the yaws start script (Klacke ?) In fact, why not change the behaviour of the start script so that any 'not known' switch is passed straight through to the invoke of 'erl' ? Cheers, Tobbe > maintain private patches for such a thing by finding a way to solve my > problem that the Yaws community likes, so that I can make patches that > have a chance of being merged into the official distribution. Perhaps > there is another solution already at hand, which I just don't realize. > > /Fredrik > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list |
From: Claes W. <kl...@gm...> - 2005-05-18 14:42:24
|
If the issue is just to add a couple of config params to=20 the yaws statup script, that is a no-brainer. I just checked in that (it's the file scripts/yaws.template in CVS) Doing what tobbe suggested, just passing unknown flags on to erlang .. well requires some thought. And finally. Fredrik. I think it makes a lot of sence for you to run yaws in embedded mode inside the actual=20 SIP server. Everything becomes much easier and nicer if you do and the config that embedded yaws server is very very simple.=20 If you send me the /etc/yaws.conf file that you want to use for the server, I'll reply ith the corresponding code snippet that starts exactly the same server, but in embedded mode. /klacke |
From: Fredrik T. <ft...@it...> - 2005-05-18 15:25:36
|
On Wednesday 18 May 2005 16.42, Claes Wikstrom wrote: > If the issue is just to add a couple of config params to > the yaws statup script, that is a no-brainer. I just checked in that > (it's the file scripts/yaws.template in CVS) Well, yes they are indeed simple. My concerns were just to not re-invent the wheel (if there were some other, better, way of accomplishing my task already) and not having to maintain private patches. I'll look at your updates a.s.a.p. Thanks. > Doing what tobbe suggested, just passing unknown flags on to erlang > .. well requires some thought. > > And finally. Fredrik. I think it makes a lot of sence for > you to run yaws in embedded mode inside the actual > SIP server. Everything becomes much easier and nicer if you do and > the config that embedded yaws server is very very > simple. I imagine that the people using the web interface wants to do access control, with IP ACL's or username/passwords. This is things they will undoubtly want to tinker with over time, which is the reason I am reluctant to run Yaws in embedded mode. As I understand it, I would then have to provide my SIP server users with a way to change the embedded Yaws configuration with regards to access control etc. and then implement functionality to tell the imbedded Yaws about the new configuration - it just seems so much more appealing to me to tell my SIP server users to install Yaws separately, configure it separately and just point some Yaws web root on a directory with .yaws-files I distribute. You have done a fine job with Yaws configuration and management, and I'd hate to ruin it ;). > If you send me the /etc/yaws.conf file that you want to use for the > server, I'll reply ith the corresponding code snippet that starts > exactly the same server, but in embedded mode. Thank you for the generous offer, if I decide to use embedded Yaws after all and have problem getting it running I'll get back to you. /Fredrik |
From: Fredrik T. <ft...@it...> - 2005-05-27 09:57:34
Attachments:
yaws-erlarg.patch1
|
On Wednesday 18 May 2005 16.42, Claes Wikstrom wrote: > If the issue is just to add a couple of config params to > the yaws statup script, that is a no-brainer. I just checked in that > (it's the file scripts/yaws.template in CVS) Hi again First, the current yaws.template is missing an end-quote on the line echo " -proto_dist Mod -- use Mod for distrib > Doing what tobbe suggested, just passing unknown flags on to erlang > .. well requires some thought. Besides the -name and -proto_dist options you so kindly added, I need to set -boot and also multiple -ssl_dist_opt values. I don't think it makes sense to add code to yaws.template for each and every parameter someone wants to send to 'erl', so I made a small patch to allow for passing of arbitrary arguments to 'erl' without passing everything not recognized to it, since you seem hesitant about that. What do you think of this as a middle way? /Fredrik |
From: Claes W. <kl...@gm...> - 2005-06-07 11:12:14
|
>=20 > What do you think of this as a middle way? >=20 Nice patch, applied. /klacke |