[AOLSERVER] AOLserver presentation at NOVALUG this Saturday
Subject pretty much says it all, this Sat May 5, I will be giving a presentation on AOLserver to Northern Virginias Linux User Group. It will probably last about 45 minutes and will have q/a followup. I will touch on history, OpenACS/NSD, capabilities, examples, etc. All are invited and the meetings are usually very informative with between 50-100 people. Previous presentations have included the author of SNORT IDS, LDAP, Ruby, etc. The web page for directions and more info in general is http://novalug.tux.org>http://novalug.tux.org
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
On 2001.05.02, Tom Jackson <[EMAIL PROTECTED]> wrote: > Dossy wrote: > > > What happens if the database update succeeds, but somewhere between > > the update and the kill/remake of the bean, the process fails? > > > > Now, the data is out of sync. > > Hopefully the data being used by the bean in this way can be relatively > up-to-date, for instance today's headlines. That's not the point of ACID. If you're not building a site that needs to meet ACID requirements, then almost _anything_ will do just fine, that includes EJB. Just as folks argue against MySQL "if you MUST have something that passes the ACID test", the same arguments can be made against EJB. Which is exactly why I find the "E" in EJB quite a misnomer. It's not suitable for building serious Enterprise level applications, at least not those that must pass the ACID test. > As long as the db passes the ACID test, that is all that matters. Be glad the people who design web interfaces to stock trading systems don't share your opinion. ;-) > Don't use the data in the bean for anything important, don't hold it > there and re-display it before committing to the db, and grabbing the > update. If you're not using Beans for important things, then why do you need to use Beans at all? > I don't see any real difference between a bean and a nsv_ element. > Probably the bean is a little more flexable, but it is all virtual > memory. The difference is that Beans offer you a layer of abstraction, which in the extreme performance demands of the Web arena, translate into unnecessary performance hindrances and overhead. - Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/
Re: [AOLSERVER] [OT] Java is a dead-end career choice.
On 2001.05.02, Alan Wright <[EMAIL PROTECTED]> wrote: > From a career point of view you are sensible to get Java experience > because there is a lot of well paid java work (here in the UK at > least). I am just about to put my life savings on the line to build a > subscription driven web service so my priorities are not future > employment driven! This is entirely off-topic, but this is a big pet peeve of mine. I HATE JAVA. I absolutely hate it. I currently get paid to write Tcl code, daily. There's some evil brewing at my workplace about using BEA WebLogic for new projects. I flat out said "my resume will be up on dice.com the same day if I get moved away from Tcl." People looked at me all strangely and said "but Java's all over the place! It'll be great for your career, there's so much money in Java!" These people either are foolish, naive, or both. Anyone who has any understanding of basic economics knows what the supply-demand curve looks like. Today, demand has reached a limit -- it's maxed out. So, the only thing that drives price is supply. At this very moment in time, supply is still limited. But, you know what? Universities around the WORLD are pumping out hundreds of thousands of graduates yearly who, with all their Java fresh in their mind, can easily get the Java 2 certification and probably some others. Lets not even begin to talk about what this does to the value of Java certified programmers ... So, as time goes on, demand will remain pegged at max while supply steadily increases. Therefore, price will steadily increase. If you're an employer, this is great news. If you're a programmer, then any investment of your time in learning Java is an exercise in diminishing returns. Currently, I'm a developer and not an employer, so you know what side I'm on ... Just as, once upon a time, a "HTML programmer" (cough, cough) could make upwards of $50-100/hour -- today, a college graduate with a $250 copy of DreamWeaver 4 can be had to do the same thing for under $12/hour. This happened from 1993 to today, only a span of 8 years. And, technology is moving in huge leaps and bounds. Java programmers that are salaried at $80-120k today probably won't be making more than $45-55k in two to three years from now -- this is only my prediction, of course. Of course, I've been wrong before, and I'll be wrong again, I'm sure, but just as some people didn't see the whole dot-com meltdown coming, they probably don't see this trend, either. - Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/
[AOLSERVER] experimental alternate odbc driver available
I've taken Rob Mayoff's DB2 driver, and made it ODBC 3.0 compliant. The benefits of this driver over the standard nsodbc module are: 1. Works with fields greater than 8192 chars in length 2. Max field size is settable on a per aolserver process level 3. autocommit is turned off, making transactions easier to create within your application 4. supports bind variables (Rob built various commands to handle input lists of variables and filenames -- this has been borrowed but untested.) 5. hooks for better support of lobs. DB/2 automatically could load/store lobs from files. Those hooks are in the code but have been disabled. I intend to write ODBC 3 compliant versions of the lob <--> file support in the driver. You can download the driver at: http://downloads.hollyjerry.org:16080/files/aolserver3.2/odbc2.tar It's very experimental at the moment. It should have the same performance characteristics as the DB2 driver and the old nsodbc module. So enjoy, and please let me know how it works. Jerry Asher = Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 Berkeley, CA 94709Fax: (877) 311-8688
Re: [AOLSERVER] dumb variable question
I've tried both nsv and nscache. Both do exactly what I need, although nscache seems to do it better. My question is with nscache how can you tell if a given cache has already been created? or am I thinking about it the wrong way? Thanks for the help... -derek --- Rob Mayoff <[EMAIL PROTECTED]> wrote: > > How can I set a variable that is available to all > page > > requests until I unset it? > > You have these options: > > - Use an nsv. http://aolserver.com/docs/nsv.adp > > - Use ns_share. This is deprecated. > > - Define a proc that returns the value. This is > only useful for > constants, and you must know the value at startup > time. > > - Use the ns_cache module. > http://www.arsdigita.com/acs-repository/download-verify?version_id=622 > > Sounds like the ns_cache module might be the most > appropriate for you. = "Are you going to spend the rest of your life selling sugar water, or are you going to come with me and change the world?" __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
If the beans don't write to the database then ACID isn't even applicable. If they do write to the database, then they're doing it through the database access method and if the database is ACID compliant, so will be the writes; again, not applicable. If the data has been modified in the database and the bean hasn't been (sic) restarted, then your readers will not have the latest data. Be aware that if this read-only data is wrong and is used for an input form of some kind, ACID will work fine when the direct write to the database happens, but you'll be writing the wrong (bean-cached) data. I know beans, but I'm assuming in this context that they're caching database queries. /s. -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Dossy Sent: Wednesday, May 02, 2001 3:33 PM To: [EMAIL PROTECTED] Subject: Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL? On 2001.05.02, Tim Darling <[EMAIL PROTECTED]> wrote: > EJBs can be ACID-compliant.. the key is you don't write new values to the > beans. > If a value needs to be updated, you write to the database and then kill > and remake the bean. This way you're keeping the database as your sole > data abstraction, and the beans are just a local mirror of some parts. You misunderstand the purpose of ACID, I think. What happens if the database update succeeds, but somewhere between the update and the kill/remake of the bean, the process fails? Now, the data is out of sync. Unless you can make the kill/remake of the bean as part of the database transaction (if the kill/remake of the bean doesn't happen, the whole operation gets rolled back) ... then it doesn't pass the ACID test. Or, am _I_ confused? - Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
Tim Destroying and instantiating beans is a very expensive process and if your site gets busy be sure you will regret such an approach. Our Tomcat ( http://www.free-minder.com ) site uses vanilla javabeans where user data is applied to bean properties and then database update methods are provided to make changes persistent as appropriate. We have made the source to the site available for download if your interested. We are not experts in Java so this may not be the "proper way", this was just the way we did it. >From a career point of view you are sensible to get Java experience because there is a lot of well paid java work (here in the UK at least). I am just about to put my life savings on the line to build a subscription driven web service so my priorities are not future employment driven! Good luck with your EJB work - it would be interesting to compare notes in 6 months after we we have both crossed over, albeit in opposite directions. Tim Darling wrote: > If a value needs to be updated, you write to the database and then kill > and remake the bean. This way you're keeping the database as your sole > data abstraction, and the beans are just a local mirror of some parts. >
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
Dossy wrote: > What happens if the database update succeeds, but somewhere between > the update and the kill/remake of the bean, the process fails? > > Now, the data is out of sync. Hopefully the data being used by the bean in this way can be relatively up-to-date, for instance today's headlines. > Unless you can make the kill/remake of the bean as part of the > database transaction (if the kill/remake of the bean doesn't > happen, the whole operation gets rolled back) ... then it doesn't > pass the ACID test. > > Or, am _I_ confused? As long as the db passes the ACID test, that is all that matters. Don't use the data in the bean for anything important, don't hold it there and re-display it before committing to the db, and grabbing the update. I don't see any real difference between a bean and a nsv_ element. Probably the bean is a little more flexable, but it is all virtual memory. --Tom Jackson
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
On 2001.05.02, Tim Darling <[EMAIL PROTECTED]> wrote: > EJBs can be ACID-compliant.. the key is you don't write new values to the > beans. > If a value needs to be updated, you write to the database and then kill > and remake the bean. This way you're keeping the database as your sole > data abstraction, and the beans are just a local mirror of some parts. You misunderstand the purpose of ACID, I think. What happens if the database update succeeds, but somewhere between the update and the kill/remake of the bean, the process fails? Now, the data is out of sync. Unless you can make the kill/remake of the bean as part of the database transaction (if the kill/remake of the bean doesn't happen, the whole operation gets rolled back) ... then it doesn't pass the ACID test. Or, am _I_ confused? - Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
Don't forget that Tomcat can run on it's own. It has built in SSL, and virtual hosting.. .. > browser to see the effect! While using Tomcat we invariably had to restart > tomcat to be sure of seeing changes to JSP pages. I am not sure but I believe > later versions of tomcat require Apache to be restarted also. ..
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
EJBs can be ACID-compliant.. the key is you don't write new values to the beans. If a value needs to be updated, you write to the database and then kill and remake the bean. This way you're keeping the database as your sole data abstraction, and the beans are just a local mirror of some parts. So if reading DB values much more than writing, you might want to consider them. If it's a 3:1 ratio then you're just creating a headache for yourself. For a site with 10,000 hits a second that call DB values that are changed once a month.. you probably want to keep a web server-RAM mirror of the data. EJBs are of course one solution, photo.net uses a similar TCL-based idea for their drop down menus, I believe, and it works well for them. Similar TCL-based ideas have worked well for me. Maybe it just comes down to wanting to sail in more mainstream waters (easier to find new programmers with experience, wanting to add your project to their resume, lots of good books as resources). My personal concern for reducing the load on my database is low on my priority list compared to those other things.. -T On Wed, 2 May 2001, Jerry Asher wrote: > At 08:48 PM 5/1/01 -0400, you wrote: > >On 2001.05.01, Tim Darling <[EMAIL PROTECTED]> wrote: > > > Further Enterprise Java Beans make websites that are > > > much faster because a DB call isn't made every time a user hits a > > > page. DB calls are 1,000 - 10,000 times slower than a call to a java bean > > > which is acting as an abstraction of the database. > > > >I can implement the equivalent of Java beans using two or three > >procs that act as wrappers around an nsv_* interface, all in > >Tcl and AOLserver API. > > I'm with both Tim and Dossy here. There's a bit market for EJBs and > there's a lot that can be done in AOLserver itself. > > I am curious: how do EJB's handle the ACID test? Is the performance > penalty a reasonable cost for those portions of your project that have ACID > requirements? Is the EJB/DB architecture more akin to a AOLserver as > application server/DB solution than the typical AOLserver as web server/DB > solution described so well in WTR? If so, does what can we learn/steal > from EJBs to make the AOLserver environment more productive, more > efficient, more powerful, or just more compatible? > > Jerry > = > Jerry Asher [EMAIL PROTECTED] > 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 > Berkeley, CA 94709Fax: (877) 311-8688 >
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
The documentation may be a little dated, but, we're on 2.3.3 and developed
our web site over a 4 year period with no access to source - only the docs.
There have been a few obscure server bugs where access to the source
would have been very helpful, but the "read the source to understand"
mentality is not necessary to develop with AOLServer, IMO.
Stuff like caching web pages to avoid DB calls - we do that in 5-10
lines of TCL, either caching in shared variables or on disk. Very simple:
Memory:
ns_share cache
-- compute cache tag for this request (maybe using URL, maybe something else)
if {[info exists cache($cachetag)] && $cache($cachetag,mtime) > [ns_time]-600} {
ns_return 200 text/html $cache($cachetag)
return
}
-- generate HTML
set cache($cachetag) $html
set cache($cachetag,mtime) [ns_time]
ns_return 200 text/html $html
Disk cache:
-- compute cache tag for this request (maybe using URL, maybe something else)
set cachefile $cachedir/$cachetag
if {[file exists $cachefile] && [file mtime $cachefile] > [ns_time]-600} {
ns_returnfile 200 text/html $cachefile
return
}
-- generate HTML
set tempfile $cachefile.[ns_time]
set fd [open $tempfile w]
puts $fd $html
close $fd
rl_mv $tempfile $cachefile (C module: "mv" command)
ns_return 200 text/html $html
I agree that the model of using layers of "black boxes" will not work
very well with web sites because of scalability issues. If there is a
hot spot on your web site, it can cause HUGE loading problems for the
entire site. If it is in the middle layers of a bunch of black box
software, how do you fix it? Adding gobs of servers is always an
option, but then it changes a one-time development problem into an
ongoing system administration problem.
Jim
>
> Many thanks to all those who took the time to reply to my question.
>
> I am hugely impressed with AOLServer and plan to do some serious evaluation of
> the product and the associated development process with my colleague over the
> next months.
>
> On balance - at this point in time I am leaning more toward AOLServer + TCL +
> Oracle than Apache/Tomcat/Javabeans etc.
>
> I feel much more comfortable about the scalability of the AOLServer model because
> bottlenecks are much easier to find and resolve in the absence of the
> multi-layered complexity inherent in the java based solutions. JVM's terrify me
> more than anything else on earth when they are let loose on my computers (except
> perhaps my 4 year old son)!
>
> During the development cycle you can only imagine the pleasure I experienced
> making a change to a bit of TCL, saving the file, and refreshing the page in the
> browser to see the effect! While using Tomcat we invariably had to restart
> tomcat to be sure of seeing changes to JSP pages. I am not sure but I believe
> later versions of tomcat require Apache to be restarted also.
>
> I have noticed some comments about the documentation - Personally, what I have
> seen so far looks good, I can buy books on TCL and I can read the source.
>
> Thanks again to all - especially those at AOL who work on the core product and
> are so willing to share the fruits of their labours.
>
> Alan Wright
>
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
Many thanks to all those who took the time to reply to my question. I am hugely impressed with AOLServer and plan to do some serious evaluation of the product and the associated development process with my colleague over the next months. On balance - at this point in time I am leaning more toward AOLServer + TCL + Oracle than Apache/Tomcat/Javabeans etc. I feel much more comfortable about the scalability of the AOLServer model because bottlenecks are much easier to find and resolve in the absence of the multi-layered complexity inherent in the java based solutions. JVM's terrify me more than anything else on earth when they are let loose on my computers (except perhaps my 4 year old son)! During the development cycle you can only imagine the pleasure I experienced making a change to a bit of TCL, saving the file, and refreshing the page in the browser to see the effect! While using Tomcat we invariably had to restart tomcat to be sure of seeing changes to JSP pages. I am not sure but I believe later versions of tomcat require Apache to be restarted also. I have noticed some comments about the documentation - Personally, what I have seen so far looks good, I can buy books on TCL and I can read the source. Thanks again to all - especially those at AOL who work on the core product and are so willing to share the fruits of their labours. Alan Wright
[AOLSERVER] encodings for win AOLserver
How can I add encodings for windows AOLserver? At moment I have only (using "encoding names"): utf-8 cp1252 identity unicode iso8859-1 My Wish terminal offers: cp860 cp861 cp862 cp863 cp864 cp865 cp866 gb12345 cp949 cp950 cp869 dingbats ksc5601 macCentEuro cp874 macUkraine jis0201 gb2312 euc-cn euc-jp macThai jis0208 iso2022-jp macIceland iso2022 jis0212 cp737 big5 euc-kr macRomania macTurkish gb1988 iso2022-kr macGreek ascii cp437 macRoman iso8859-1 iso8859-2 iso8859-3 macCroatian koi8-r iso8859-4 iso8859-5 cp1250 macCyrillic iso8859-6 cp1251 macDingbats iso8859-7 cp1252 iso8859-8 cp1253 iso8859-9 cp1254 cp1255 cp850 cp1256 cp932 identity cp1257 cp852 macJapan cp1258 shiftjis utf-8 cp855 cp936 symbol cp775 unicode cp857 So how can I make cp1257 and cp 1251 available in AOLserver windows version?
Re: [AOLSERVER] aolserver documentation
BLAARGH. My question has been answered so this god-forsaken thread I started can die. This is all degenerating into a discussion that has already happened countless times in countless software threads... I've heard enough concerns, whetherv alid or invalid, about the amount and quality of aolserver resources to ask if there were any projects to improve and expand what is here, however good it may be at this point. Thanks to all you guys that gave productive input and pointed me in the direction of other aolserver resources. -derek > Sometimes I hate continuing a discussion that seems > very off track. What > is better, an exhaustive O'Reilly 'Definitive > Guide', or relatively > complete docs and a community willing to help > someone who has at least > read the docs that exist? I can count on one hand > the new commands > introduced over the last three years. The commands > that are poorly > documented, will probably never be useful to anyone > unable to read > through the C source. > > Even a complete novice, like me when I stumbled onto > AOLserver, should > be able to figure out how to get things working. And > things have > significantly inproved over the last three years. > > I'm not complaining or arguing with Dossy or anyone > else who contributes > to this discussion, rather, I just wonder why we all > rush to apologize > to someone who doesn't even appear to have set up a > site using > AOLserver. > > If someone's use of AOLserver depends on other > people's opinion of the > completeness of the docs, what can we say? > > The truth is these docs are pretty much consistent > with any O'Reilly > 'Definitive Guide', after a chapter or two tacked > onto the front of the > book so bookstore junkies actually buy the book, you > have a listing of > the API, and no real examples. What you really need > is to be able to ask > a question and get an answer in a reasonable amount > of time. Use the > discussion groups! > > Another truth is that if you can program in Tcl, > picking up the > AOLserver api is going to be a snap. So anything > that teaches you Tcl > will teach you AOLserver. I would recommend > Ousterhout's _Tcl and the Tk > Toolkit_ , which might be slightly outdated, but > offers the best overall > coverage of the why and how of Tcl. > > > --Tom Jackson = "Are you going to spend the rest of your life selling sugar water, or are you going to come with me and change the world?" __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: [AOLSERVER] AOLServer+ACS+Java <= AOLServer+TCL?
At 08:48 PM 5/1/01 -0400, you wrote: >On 2001.05.01, Tim Darling <[EMAIL PROTECTED]> wrote: > > Further Enterprise Java Beans make websites that are > > much faster because a DB call isn't made every time a user hits a > > page. DB calls are 1,000 - 10,000 times slower than a call to a java bean > > which is acting as an abstraction of the database. > >I can implement the equivalent of Java beans using two or three >procs that act as wrappers around an nsv_* interface, all in >Tcl and AOLserver API. I'm with both Tim and Dossy here. There's a bit market for EJBs and there's a lot that can be done in AOLserver itself. I am curious: how do EJB's handle the ACID test? Is the performance penalty a reasonable cost for those portions of your project that have ACID requirements? Is the EJB/DB architecture more akin to a AOLserver as application server/DB solution than the typical AOLserver as web server/DB solution described so well in WTR? If so, does what can we learn/steal from EJBs to make the AOLserver environment more productive, more efficient, more powerful, or just more compatible? Jerry = Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 Berkeley, CA 94709Fax: (877) 311-8688
