From: Todd G. <t.g...@gm...> - 2012-12-14 14:21:58
|
Yaws has lots of great documentation, and then there is the helpful 132pg pamphlet, 'Building Web Applications with Erlang'. But I'm still left with some basic questions regarding app creation. Overall, I'm still wondering, where do app files go? And why are there so many files in the yaws root? 1. When creating a simple web app, where do the various files go? For example, it's clear that .yaws and other webby files go under ./www. But what about other files, such as .erl? Or appmods, nif and port files? 2. The documentation for creating a yapp is a bit confusing... http://yaws.hyber.org/yapp_intro.yaws """ ebin_dir = /<yaws_root>/{applications,lib}/yapp/ebin The "applications" part is used for a local_installed Yaws, and "lib" for a real installed one. Then we make sure that the yapp handler application is started when Yaws is started, by using the runmod directive """ Um..., what is the difference between 'applications' and 'lib'? 3. Root file structure...wow, lots of files here... """ 734945 -rw-r--r-- 1 todd staff 143891 Dec 14 08:46 ChangeLog 734946 -rw-r--r-- 1 todd staff 1526 Dec 14 08:46 LICENSE 734947 -rw-r--r-- 1 todd staff 2809 Dec 14 08:46 Makefile 734948 -rw-r--r-- 1 todd staff 3780 Dec 14 08:46 README 734949 -rw-r--r-- 1 todd staff 295 Dec 14 08:46 README.pkg-config 734950 -rw-r--r-- 1 todd staff 2611 Dec 14 08:46 README.win32-cygwin 734951 -rw-r--r-- 1 todd staff 97 Dec 14 08:46 _build.cfg 734952 drwxr-xr-x 6 todd staff 204 Dec 14 08:46 applications 735160 drwxr-xr-x 3 todd staff 102 Dec 14 08:46 bin 735162 drwxr-xr-x 9 todd staff 306 Dec 14 08:46 c_src 735170 -rwxr-xr-x 1 todd staff 42080 Dec 14 08:46 config.guess 735171 -rwxr-xr-x 1 todd staff 30400 Dec 14 08:46 config.sub 735172 -rw-r--r-- 1 todd staff 9406 Dec 14 08:46 configure.in 735173 drwxr-xr-x 7 todd staff 238 Dec 14 08:46 contrib 735184 drwxr-xr-x 3 todd staff 102 Dec 14 08:46 debian 735186 drwxr-xr-x 10 todd staff 340 Dec 14 08:46 doc 735195 drwxr-xr-x 3 todd staff 102 Dec 14 08:46 ebin 735197 drwxr-xr-x 5 todd staff 170 Dec 14 08:46 examples 735209 drwxr-xr-x 9 todd staff 306 Dec 14 08:46 include 735208 -rw-r--r-- 1 todd staff 2066 Dec 14 08:46 include.mk.in 735217 -rwxr-xr-x 1 todd staff 5584 Dec 14 08:46 install-sh 735218 -rw-r--r-- 1 todd staff 979 Dec 14 08:46 known_dialyzer_warnings 735219 drwxr-xr-x 7 todd staff 238 Dec 14 08:46 man 735225 drwxr-xr-x 5 todd staff 170 Dec 14 08:46 munin 735229 drwxr-xr-x 11 todd staff 374 Dec 14 08:46 priv 735240 -rw-r--r-- 1 todd staff 1181 Dec 14 08:46 rebar.config 735241 -rw-r--r-- 1 todd staff 736 Dec 14 08:46 rebar.config.script 735242 drwxr-xr-x 4 todd staff 136 Dec 14 08:46 rel 735251 drwxr-xr-x 23 todd staff 782 Dec 14 08:46 scripts 735285 drwxr-xr-x 57 todd staff 1938 Dec 14 08:46 src 735341 drwxr-xr-x 6 todd staff 204 Dec 14 08:46 ssl 735350 drwxr-xr-x 18 todd staff 612 Dec 14 08:47 test 735485 -rw-r--r-- 1 todd staff 4780 Dec 14 08:47 two-mode-mode.el 735486 -rw-r--r-- 1 todd staff 14 Dec 14 08:47 vsn.mk 735487 drwxr-xr-x 12 todd staff 408 Dec 14 08:47 win32 735499 drwxr-xr-x 92 todd staff 3128 Dec 14 08:47 www 735734 -rw-r--r-- 1 todd staff 300 Dec 14 08:47 yaws.pc.in 735735 -rw-r--r-- 1 todd staff 203 Dec 14 08:47 yaws.rel.src """ Think about this from the standpoint of someone new (like me) to your webserver. Why am I presented with all these config files, a dir for debian and win32... etc. Couldn't all this be restructured in a cleaner way? 4. New app creation is confusing enough, but the docs for embedding yaws make my eyes glaze over...seriously, do I need to wade thru all this? http://yaws.hyber.org/embed.yaws Could you simply make a rebar plugin or makefile to auto generate all this boilerplate? 5. In general, creating a new app from scratch should be much easier on the developer. Are there plans for creating rebar plugins to: * create a new yaws app stack * create an embedded yaws app stack * add an appmod * add a yapp For my current project, I started out looking at yaws but abandoned it for cowboy b/c of all the above friction. Then, I ran into a problem extracting query string params in cowboy. The error msg wasn't useful, there were no docs for that feature, and I didn't want to debug it and/or bother the owner. So I came back to yaws b/c it had documentation. I really enjoy using it, but I'm left with the overall feeling that I'm not 'doing it right'. -- Todd |
From: Tjeerd v. d. L. <tj...@yo...> - 2012-12-14 20:22:32
|
Hello Todd, This is not a compete answer to all your questions. I guess you should start with http://yaws.hyber.org/yaws.pdf which offers good reading. I do not see Yaws is more complex in its setup than for instance Apache if you install it from source. > 1. When creating a simple web app, where do the various files go? For > example, it's clear that .yaws and other webby files go under ./www. But > what about other files, such as .erl? Or appmods, nif and port files? The .erl files are source files and the appmods and so on are Erlang compiled files. The first ones usually are placed in your projects source directory. The latter need to be placed in a directory which is searched by Erlang. You can add any path to the ebin_dir directive so it is flexibility that is your part, comparable with a search path for libraries in your OS. > 3. Root file structure...wow, lots of files here... Most Linux distributions (at least the Debian and Redhat based ones) offer a package. The source from github of course needs to be support multiple platforms. Building from source looks therefore always a little more complex. > 4. New app creation is confusing enough, but the docs for embedding yaws > make my eyes glaze over...seriously, do I need to wade thru all this? I do not think it can be made much easier but then again I think it is beyond usual web application setup. Look for a prebuilt package for your distribution if you want a more predefined setup. Regards, Tjeerd. |
From: Christopher F. <chr...@ca...> - 2012-12-14 22:54:43
Attachments:
signature.asc
|
On 14/12/2012 15:21, Todd œ wrote: > Yaws has lots of great documentation, and then there is the helpful > 132pg pamphlet, 'Building Web Applications with Erlang'. But I'm still > left with some basic questions regarding app creation. Overall, I'm > still wondering, where do app files go? And why are there so many files > in the yaws root? > > 1. When creating a simple web app, where do the various files go? For > example, it's clear that .yaws and other webby files go under ./www. But > what about other files, such as .erl? Or appmods, nif and port files? > First of all, there is not only one answer to this question. It is highly dependent of your application. One option is to develop your application like a classic Erlang application[1]. You could also take a look on what is done with the debian packages of yaws: * erlang-yaws[2] includes the Erlang Yaws application * yaws[3] includes binaries and config to run Yaws in standalone mode * yaws-yapp[4] includes the Yapp application > 2. The documentation for creating a yapp is a bit confusing... > > http://yaws.hyber.org/yapp_intro.yaws > """ > ebin_dir = /<yaws_root>/{applications,lib}/yapp/ebin > > The "applications" part is used for a local_installed Yaws, and "lib" > for a real installed one. Then we make sure that the yapp handler > application is started when Yaws is started, by using the runmod directive > """ > > Um..., what is the difference between 'applications' and 'lib'? > See http://yaws.hyber.org/configuration.yaws to know the difference between a local installation and a real installation. You probably need to use a real installation of Yaws. Local installation is generally used for development purpose. > > 3. Root file structure...wow, lots of files here... [...] > Think about this from the standpoint of someone new (like me) to your > webserver. Why am I presented with all these config files, a dir for > debian and win32... etc. Couldn't all this be restructured in a cleaner way? > This is the root directory of the project. You should install Yaws before using it. With a typical installation, you have the following structure: * etc files went into /etc * executables went into /usr/bin * library files went into /usr/yaws/lib/yaws * var files went into /var * default docroot went into /var/yaws/www > 4. New app creation is confusing enough, but the docs for embedding yaws > make my eyes glaze over...seriously, do I need to wade thru all this? > No, the easiest way to do is to run Yaws in standalone mode. You can embed Yaws, of course, but in a larger application. > 5. In general, creating a new app from scratch should be much easier on > the developer. Are there plans for creating rebar plugins to: > > * create a new yaws app stack > * create an embedded yaws app stack > * add an appmod > * add a yapp > What do you really mean by "a new app" ? * Yapp _IS_ an application. it just need to be installed and configured. Maybe the documentation should be improved but rebar has nothing to do here. * An appmod is just a single Erlang module which exports the function out/1 (see http://yaws.hyber.org/appmods.yaws). > > For my current project, I started out looking at yaws but abandoned it > for cowboy b/c of all the above friction. Then, I ran into a problem > extracting query string params in cowboy. The error msg wasn't useful, > there were no docs for that feature, and I didn't want to debug it > and/or bother the owner. So I came back to yaws b/c it had > documentation. I really enjoy using it, but I'm left with the overall > feeling that I'm not 'doing it right'. > What do you want to do ? It would be easier to help you with details on your application. [1] http://www.erlang.org/doc/design_principles/applications.html#app_dir [2] http://packages.debian.org/sid/amd64/erlang-yaws/filelist [3] http://packages.debian.org/sid/all/yaws/filelist [4] http://packages.debian.org/sid/all/yaws-yapp/filelist -- Christopher |
From: Todd Greenwood-G. <t.g...@gm...> - 2012-12-15 14:15:08
|
Christopher, Tjeerd - Thank you for your responses. I think the disconnect here is that I'm approaching this with the goal of building stand-alone applications, where the front end (user interface) is decoupled from the back end: Application ------------ * user interface web|qt|whatever -> talking REST to backend * backend REST backend (could be python|java|erlang|whatever) I've written a test bed application suite consisting of the following application stacks: Test Apps --------- 1. Common WebApp angularjs web app talking REST and websockets to backend 2. Desktop/Server REST/Websockets implemented on jetty and erlang (cowboy|yaws) 3. Android Mobile REST/Websockets implemented on i-jetty (standard java servlets) So basically, I deploy a common webapp to a variety of containers as a way of both learning the various technologies, and also as a way of developing a template for developing cross platform applications. I can see how yaws was probably developed to be installed on a server once, and then applications would be installed into it via adding an ebin_dir entry in yaws.conf. Thats certainly clean and simple. Correct me if I'm wrong, but it does seem a bit different from the rebar/erlang way of doing things. When creating apps with rebar and reltools, the approach seems to be: declare your deps, and package up everything into a fat release, including your erlang distribution. It took me awhile to get comfortable with that approach, too... I kept thinking, "what? I'm including the entire erlang runtime with every application?" Seemed crazy when I first saw it. But I can see the advantages now. Anyway, even though I'm writing a smallish application, perhaps embedding yaws is the appropriate strategy... Thanks again, -Todd p.s. As a side note... With respect to a permanently installed service, such as a java servlet container...I'm used to deploying a war to the server, blah blah. The app definition/interface is simple, and deploying the bits to the servers is all very similar. So, when yaws is installed as a service... what's the common way of packaging up a 'yaws web application' and deploying it to a 'yaws server'? In practice, do you really just copy your app to a dir on your production server and manually (or via puppet/chef/whatever) update your yaws.conf ebin_dir entries? -t On 12/14/2012 05:54 PM, Christopher Faulet wrote: > On 14/12/2012 15:21, Todd œ wrote: >> Yaws has lots of great documentation, and then there is the helpful >> 132pg pamphlet, 'Building Web Applications with Erlang'. But I'm still >> left with some basic questions regarding app creation. Overall, I'm >> still wondering, where do app files go? And why are there so many files >> in the yaws root? >> >> 1. When creating a simple web app, where do the various files go? For >> example, it's clear that .yaws and other webby files go under ./www. But >> what about other files, such as .erl? Or appmods, nif and port files? >> > > First of all, there is not only one answer to this question. It is > highly dependent of your application. > > One option is to develop your application like a classic Erlang > application[1]. > You could also take a look on what is done with the debian packages of yaws: > * erlang-yaws[2] includes the Erlang Yaws application > * yaws[3] includes binaries and config to run Yaws in standalone mode > * yaws-yapp[4] includes the Yapp application > >> 2. The documentation for creating a yapp is a bit confusing... >> >> http://yaws.hyber.org/yapp_intro.yaws >> """ >> ebin_dir = /<yaws_root>/{applications,lib}/yapp/ebin >> >> The "applications" part is used for a local_installed Yaws, and "lib" >> for a real installed one. Then we make sure that the yapp handler >> application is started when Yaws is started, by using the runmod directive >> """ >> >> Um..., what is the difference between 'applications' and 'lib'? >> > > See http://yaws.hyber.org/configuration.yaws to know the difference > between a local installation and a real installation. You probably need > to use a real installation of Yaws. Local installation is generally used > for development purpose. > >> >> 3. Root file structure...wow, lots of files here... > [...] >> Think about this from the standpoint of someone new (like me) to your >> webserver. Why am I presented with all these config files, a dir for >> debian and win32... etc. Couldn't all this be restructured in a cleaner way? >> > > This is the root directory of the project. You should install Yaws > before using it. With a typical installation, you have the following > structure: > > * etc files went into /etc > * executables went into /usr/bin > * library files went into /usr/yaws/lib/yaws > * var files went into /var > * default docroot went into /var/yaws/www > > >> 4. New app creation is confusing enough, but the docs for embedding yaws >> make my eyes glaze over...seriously, do I need to wade thru all this? >> > > No, the easiest way to do is to run Yaws in standalone mode. You can > embed Yaws, of course, but in a larger application. > > >> 5. In general, creating a new app from scratch should be much easier on >> the developer. Are there plans for creating rebar plugins to: >> >> * create a new yaws app stack >> * create an embedded yaws app stack >> * add an appmod >> * add a yapp >> > > What do you really mean by "a new app" ? > * Yapp _IS_ an application. it just need to be installed and > configured. Maybe the documentation should be improved but rebar has > nothing to do here. > * An appmod is just a single Erlang module which exports the function > out/1 (see http://yaws.hyber.org/appmods.yaws). > > >> >> For my current project, I started out looking at yaws but abandoned it >> for cowboy b/c of all the above friction. Then, I ran into a problem >> extracting query string params in cowboy. The error msg wasn't useful, >> there were no docs for that feature, and I didn't want to debug it >> and/or bother the owner. So I came back to yaws b/c it had >> documentation. I really enjoy using it, but I'm left with the overall >> feeling that I'm not 'doing it right'. >> > > What do you want to do ? It would be easier to help you with details on > your application. > > > [1] http://www.erlang.org/doc/design_principles/applications.html#app_dir > [2] http://packages.debian.org/sid/amd64/erlang-yaws/filelist > [3] http://packages.debian.org/sid/all/yaws/filelist > [4] http://packages.debian.org/sid/all/yaws-yapp/filelist > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > > > > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > -- Todd Greenwood-Geer |
From: Todd Greenwood-G. <t.g...@gm...> - 2012-12-15 15:44:28
|
Ok, getting yaws running as an embedded app wasn't so hard, after all... Now, the directory structure that I deal with is nice and clean: [todd@quebec-01 rebar-yaws (master)]$ tree -L 2 . ├── deps │ ├── mimetypes │ ├── mochiweb │ └── yaws ├── ebin │ ├── launch.beam │ ├── myapp.app │ ├── myapp_app.beam │ └── myapp_sup.beam ├── Makefile ├── rebar.config ├── src │ ├── launch.erl │ ├── myapp_app.erl │ ├── myapp.app.src │ └── myapp_sup.erl └── webapp └── webappname I use a trimmed down Makefile from cowboy, that's probably got a long lineage... https://gist.github.com/4296427 My rebar.config is pretty basic... https://gist.github.com/4296472 And, as the line in the makefile shows ('erl -pa ebin deps/*/ebin -s launch ...'), I just have a simple launch.erl to start things up... https://gist.github.com/4296452 Thanks again. I'm looking forward to exploring yaws more. -Todd links http://yaws.hyber.org/embed.yaws http://stackoverflow.com/questions/11876263/yaws-as-rebar-dependency On 12/15/2012 09:14 AM, Todd Greenwood-Geer wrote: > Christopher, Tjeerd - > > Thank you for your responses. I think the disconnect here is that I'm > approaching this with the goal of building stand-alone applications, > where the front end (user interface) is decoupled from the back end: > > Application > ------------ > * user interface > web|qt|whatever -> talking REST to backend > * backend > REST backend (could be python|java|erlang|whatever) > > > I've written a test bed application suite consisting of the following > application stacks: > > Test Apps > --------- > 1. Common WebApp > angularjs web app talking REST and websockets to backend > 2. Desktop/Server > REST/Websockets implemented on jetty and erlang (cowboy|yaws) > 3. Android Mobile > REST/Websockets implemented on i-jetty (standard java servlets) > > So basically, I deploy a common webapp to a variety of containers as a > way of both learning the various technologies, and also as a way of > developing a template for developing cross platform applications. > > I can see how yaws was probably developed to be installed on a server > once, and then applications would be installed into it via adding an > ebin_dir entry in yaws.conf. Thats certainly clean and simple. > > Correct me if I'm wrong, but it does seem a bit different from the > rebar/erlang way of doing things. When creating apps with rebar and > reltools, the approach seems to be: declare your deps, and package up > everything into a fat release, including your erlang distribution. It > took me awhile to get comfortable with that approach, too... I kept > thinking, "what? I'm including the entire erlang runtime with every > application?" Seemed crazy when I first saw it. But I can see the > advantages now. > > Anyway, even though I'm writing a smallish application, perhaps > embedding yaws is the appropriate strategy... > > Thanks again, > -Todd > > p.s. > > As a side note... > > With respect to a permanently installed service, such as a java servlet > container...I'm used to deploying a war to the server, blah blah. The > app definition/interface is simple, and deploying the bits to the > servers is all very similar. So, when yaws is installed as a service... > what's the common way of packaging up a 'yaws web application' and > deploying it to a 'yaws server'? In practice, do you really just copy > your app to a dir on your production server and manually (or via > puppet/chef/whatever) update your yaws.conf ebin_dir entries? > > -t > > On 12/14/2012 05:54 PM, Christopher Faulet wrote: >> On 14/12/2012 15:21, Todd œ wrote: >>> Yaws has lots of great documentation, and then there is the helpful >>> 132pg pamphlet, 'Building Web Applications with Erlang'. But I'm still >>> left with some basic questions regarding app creation. Overall, I'm >>> still wondering, where do app files go? And why are there so many files >>> in the yaws root? >>> >>> 1. When creating a simple web app, where do the various files go? For >>> example, it's clear that .yaws and other webby files go under ./www. But >>> what about other files, such as .erl? Or appmods, nif and port files? >>> >> >> First of all, there is not only one answer to this question. It is >> highly dependent of your application. >> >> One option is to develop your application like a classic Erlang >> application[1]. >> You could also take a look on what is done with the debian packages of >> yaws: >> * erlang-yaws[2] includes the Erlang Yaws application >> * yaws[3] includes binaries and config to run Yaws in standalone mode >> * yaws-yapp[4] includes the Yapp application >> >>> 2. The documentation for creating a yapp is a bit confusing... >>> >>> http://yaws.hyber.org/yapp_intro.yaws >>> """ >>> ebin_dir = /<yaws_root>/{applications,lib}/yapp/ebin >>> >>> The "applications" part is used for a local_installed Yaws, and "lib" >>> for a real installed one. Then we make sure that the yapp handler >>> application is started when Yaws is started, by using the runmod >>> directive >>> """ >>> >>> Um..., what is the difference between 'applications' and 'lib'? >>> >> >> See http://yaws.hyber.org/configuration.yaws to know the difference >> between a local installation and a real installation. You probably need >> to use a real installation of Yaws. Local installation is generally used >> for development purpose. >> >>> >>> 3. Root file structure...wow, lots of files here... >> [...] >>> Think about this from the standpoint of someone new (like me) to your >>> webserver. Why am I presented with all these config files, a dir for >>> debian and win32... etc. Couldn't all this be restructured in a >>> cleaner way? >>> >> >> This is the root directory of the project. You should install Yaws >> before using it. With a typical installation, you have the following >> structure: >> >> * etc files went into /etc >> * executables went into /usr/bin >> * library files went into /usr/yaws/lib/yaws >> * var files went into /var >> * default docroot went into /var/yaws/www >> >> >>> 4. New app creation is confusing enough, but the docs for embedding yaws >>> make my eyes glaze over...seriously, do I need to wade thru all this? >>> >> >> No, the easiest way to do is to run Yaws in standalone mode. You can >> embed Yaws, of course, but in a larger application. >> >> >>> 5. In general, creating a new app from scratch should be much easier on >>> the developer. Are there plans for creating rebar plugins to: >>> >>> * create a new yaws app stack >>> * create an embedded yaws app stack >>> * add an appmod >>> * add a yapp >>> >> >> What do you really mean by "a new app" ? >> * Yapp _IS_ an application. it just need to be installed and >> configured. Maybe the documentation should be improved but rebar has >> nothing to do here. >> * An appmod is just a single Erlang module which exports the function >> out/1 (see http://yaws.hyber.org/appmods.yaws). >> >> >>> >>> For my current project, I started out looking at yaws but abandoned it >>> for cowboy b/c of all the above friction. Then, I ran into a problem >>> extracting query string params in cowboy. The error msg wasn't useful, >>> there were no docs for that feature, and I didn't want to debug it >>> and/or bother the owner. So I came back to yaws b/c it had >>> documentation. I really enjoy using it, but I'm left with the overall >>> feeling that I'm not 'doing it right'. >>> >> >> What do you want to do ? It would be easier to help you with details on >> your application. >> >> >> [1] http://www.erlang.org/doc/design_principles/applications.html#app_dir >> [2] http://packages.debian.org/sid/amd64/erlang-yaws/filelist >> [3] http://packages.debian.org/sid/all/yaws/filelist >> [4] http://packages.debian.org/sid/all/yaws-yapp/filelist >> >> >> >> ------------------------------------------------------------------------------ >> >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> >> >> >> _______________________________________________ >> Erlyaws-list mailing list >> Erl...@li... >> https://lists.sourceforge.net/lists/listinfo/erlyaws-list >> > > -- Todd Greenwood-Geer |
From: Steve V. <vi...@ie...> - 2012-12-16 21:26:59
|
Others have already chimed in and helped, but I just wanted to add the comments below: On Fri, Dec 14, 2012 at 9:21 AM, Todd Greenwood <t.g...@gm...>wrote: > For my current project, I started out looking at yaws but abandoned it for cowboy b/c of all the above friction. Then, I ran into a problem > extracting query string params in cowboy. The error msg wasn't useful, > there were no docs for that feature, and I didn't want to debug it > and/or bother the owner. So I came back to yaws b/c it had > documentation. I really enjoy using it, but I'm left with the overall > feeling that I'm not 'doing it right'. > I'd recommend asking specific questions about your app in cases like this. Generally I think you'll find that you get helpful answers pretty quickly on this list. Also keep in mind that yaws is nearly a decade older than rebar, and so the way yaws has been successfully deployed for years naturally differs from the rebar approach. Adding to that is the fact that there are non-trivial differences between an Apache-like server deployment model and an embedded deployment model, yet unlike other Erlang web servers yaws supports both pretty well. Yaws has rebar support, of course, but if you find issues or problems with it, please just report them here or as github issues on the yaws repo and we'll address them pretty quickly. And finally, if you have ideas or suggestions that would make the combination of rebar and embedded yaws easier from the development or deployment perspectives, let us know about that too. thanks, --steve |