yaws

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

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('incomingproxy@...',
                 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

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('incomingproxy@...',
>                  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
> Erlyaws-list@...
> https://lists.sourceforge.net/lists/listinfo/erlyaws-list

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

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

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

>=20
> What do you think of this as a middle way?
>=20

Nice patch, applied.


/klacke