- Zope - Zope lists

RE: [Zope] Traceback? Codechange!
by Marcus Collins 29 May '00

29 May '00

> -----Original Message----- > From: Tino Wildenhain [mailto:tino@wildenhain.de] > Sent: 29 May 2000 15:44 > To: Marcus Collins > Cc: 'Chris Withers'; Martijn Pieters; Patrick J.M. Keane; > zope(a)zope.org > Subject: Re: [Zope] Traceback? Codechange! > > Hi, [...] > This is very ugly imho. It schould be sufficient, if one includes the > traceback-variable into the standard-error where its appropriate. > In the current implementation it will break the HTML-standard with > code outside <HTML></HTML> and additionally makes it impossible to get > error-messages to picky browsers, such as WAP-devices. I second this -- despite the traceback being sometimes crucial to debug errors, its inclusion after the closing HTML tag goes against the standard. Furthermore, the traceback *could* sometimes be considered to pose a security risk, since it exposes the names of methods in the call stack, some of which should not necessarily be callable through the web. Or am I just being paranoid? > Is it ok if we remove these lines? I think there should be a knob to turn it off... and not for the whole site, but for a subtree (perhaps even on a folder-by-folder basis). That way, the folks who develop and deploy on a single Zope server (does anyone do this?) can keep their tracebacks on sites under development, but get rid of them on live sites. > Do I have to copy this message to the collector and wait for > a couple of months or can we do it instantly? ;-) *grin* > Regards > Tino Wildenhain -- Marcus

3 3

The agony of the ZOPE Documentation
by jiva＠devware.com 29 May '00

29 May '00

I'm sorry, but I have to say, the ZOPE documentation, despite efforts to improve it, is absolutely, positively horrible. Not because the content isn't there, but because the tools to access it simply suck. I can type in searches on both zope.org and zdp.zope.org and though I KNOW the information is there, I can't get the results I want! Constantly, when I am recommending ZOPE to people, the ONE thing I and they complain about is the horrible documentation! Is there some way that I can get a copy of all of the FAQ's, HOW-TOs, Ref manuals, etc in some kind of raw ASCII text format or HTML or something, so that I can build some kind of useful search engine for this stuff? The search engines on www.zope.org and zdp.zope.org just plain suck. Additionally, the zdp web site is a real nice idea that is SO poorly executed IMO as to make it totally unusable. You can't even browse the documentation without clicking through a thousand different links. (I can give you specific examples of how to improve the site if you want.) Please, anyone? Save Zope's documentation! -- Some husbands are living proof that a woman can take a joke.

13 17

Q: Accessing a ZSQL Method from an External Method
by a.wacknitz＠francotyp.com 29 May '00

29 May '00

Hi all, I want to use ZSQL Methods from within External Methods and have already read the appropriate HowTo but it is somehow vague in some respects and I have some problems with my adaption. I have ZSQL methods in a subfolder /SQL, eg. /SQL/sqlZuordnung My External Method named "extShow" should use the ZSQL method sqlZuordnung: def Show(self, zuordnungsbereich, zuordnung): """Show retrieves some database items.""" res=self.SQL.sqlZuordnung(zuordnungsbereich=zuordnungsbereich, zuordnung=zuordnung) fields2index={} fieldnames=res._schema.items() for i in range(len(fieldnames)): fields2index[fieldnames[i][0]]=fieldnames[i][1] id_val=res[0][fields2index['ID']] return id_val First, I want to know how to call this function, especially how to submit the correct namespace. Calling it with <dtml-var "extShow(_, zuordnungsbereich, zuordnung)"> results in an AttributeError (SQL). Here's a TraceBack:  So, what am I doing wrong here? TIA, Andreas ********************************************************************** This email message has been swept by MIMEsweeper for the presence of computer viruses. Francotyp-Postalia AG & Co.

1 0

Hadar's Thoughts on Perl for Zope (LONG)
by Hadar Pedhazur 29 May '00

29 May '00

It's been a while since I've communicated directly with the Zope community, and I am truly sorry for that. I have been so busy, that I have actually disengaged from the mailing lists, something I was hoping to avoid doing. I have maintained the same level of involvement with Digital Creations, and therefore Zope as well, but the amount of traffic on the lists was overwhelming me given my current activity level at Opticality. I have only seen a single post to the list regarding the recent announcement of Perl for Zope. Paul Everitt was kind enough to directly forward to me Eric Sink's post, because he knows how highly I regard Eric's opinions. The most important part of that post was Eric's clear statement that there was discord in the community over this announcement. Having been one of the instrumental people in bringing Zope to the community, and having likely been the driving force behind the decision to create Perl for Zope, I would like to directly share the thoughts behind that decision. Please recognize that I have not read any of the posts on the list, and therefore, could very well be repeating important concepts written by others. I apologize if that ends up being the case, but rest assured that this would only mean that I am further underscoring those thoughts, because I didn't have the benefit of reading them first. First, a brief history lesson. I was a major Perl coder for 5 years. I built multi-thousand line Perl programs that did pretty sophisticated things, so I knew Perl pretty well. Then I discovered Python. I haven't written a line of Perl since then. This is not a put-down of Perl, but rather an elevation of Python, IMHO. It is through my discovery of Python that I came across Digital Creations (DC), in 1995. I contacted DC in 1997, and asked them if they were interested in funding. We consummated a deal in October of 1998. The deal happened only because they were a Python shop. A month later, after lots of "active discussion", we decided to Open Source the then named Principia application server. I was a driver of that decision as well. So, for the record, I'm a deeply rooted Python person, and believe it to be the ideal foundation for Zope. So, why would I push for the decision to create Perl for Zope? When I was at Union Bank of Switzerland (UBS), I used a tool that hooked into the Objective-C runtime, and unified the object model so that it was equally accessible from Objective-C, TCL, Perl and Python. Classes, methods, instance data, etc., were interchangeable, and worked transparently across languages. This was simply magic, and we made excellent use of this in a variety of our applications. Given how wonderful Zope was, it seemed to me that it too could be the foundation for people who had skills in other languages. My original thought was to use the same tool I used at UBS and incorporate it into Zope. This would have allowed TCL to interact as a first class citizen along with Perl. After much thought on the subject, we decided instead to partner with ActiveState (AS). This adds only Perl support (for the moment), but accomplishes a number of other goals, which will hopefully give the community some insight as to DC's direction on this. AS has significant Perl Zen, but has also recently hired some of the top Python talent around. They are embracing Python in a significant way, through Zope, but also as a standalone programming and scripting environment. For more on that, read: http://www.activestate.com/Corporate/Media_Center/News/Press959117519.html (the above will likely have wrapped poorly, and should be re-pasted as one long URL.) There's a more important point here though, and that is that if DC had taken my original approach, we'd have been in the business of managing the cross-platform codebase directly. In fact, that alone was one of the gating factors in not doing it. By outsourcing the cross-platform parts to AS, we each continue to concentrate on our own core competencies. For DC, that's Python, through and through. We've got a world-class team of Python experts, and that hasn't (and won't) change just because our platform will now allow others to hook their code into it. The people internally view this as a positive thing, so they don't feel that they will be forced to code in Perl. To reiterate, Zope is Python, and always will be. Meaning, the core of Zope will continue to be developed in Python (and C), and no one today envisions that changing. However, there was no uproar when we introduced XML-RPC. No one said "Hey, I don't want to be able to communicate with other systems, Zope rules, and others must perish!" Likewise, introducing a tighter coupling, giving others a choice in using their favorite language shouldn't cause you any more grief. To me, it's about "inclusion", not about change. I'm told that one of the protestations is that people will be expected to know Perl if they want to get a job coding in Zope. I guess I have a hard time understanding the problem here. Today, those shops that do most of their work in Perl, don't use Zope. So, they won't hire you anyway. Those who have already embraced Zope, will want you for your knowledge of Zope, and probably Python specifically. If Perl for Zope ends up getting Zope installed in a wider variety of shops and sites, then the above might become true. Wouldn't it also be true that there never would have been an opportunity for you to get a job there had they not adopted Zope either? My point is that if Zope gets wider adoption because it permits a wider range of programming choices to script its core, then more jobs will be available. At some shops, those jobs will have to be in Perl. But at others, "Best Practices" will rule, and we at DC (and I too) believe that this will continue to be Python. In fact, I could argue strongly that indeed even in the pure Perl shops that adopt Zope, they'll want/need a Python guru or two to track the core of Zope, in case they ever need to tweak that as well. This will create a larger job-base for the Python people than we have now. Here's my bottom line, and a bit of a rub as well. The Perl for Zope initiative is meant to be one which purely and simply helps the community, by broadening support for Zope, and getting it more widely adopted. DC is not intending to become a Perl consulting shop, so it likely won't have a near-term direct influence on our revenues. In fact, it will add to our expenses, as we support this wider community. So, we've undertaken this with a view toward others, rather than what's best for us in a "mercenary" sense. I would hope that you would all join us in that view and mission. Finally, I apologize deeply for the fact that I won't have the time to debate this interactively with the community. I will ask Paul to keep me up to speed on the nature of the responses, and if requested, or required, I'll post again with a summary follow-up of my views. I wish to conclude by repeating the original introduction here. I am a deep supporter of Python, as are all of the employees at DC. I am deep supporter of the Open Source movement, as are all of the employees at DC. I am deeply committed to keeping the core of Zope in pure Python and C, so that we can continue to deliver on the promise of our Services-based business. I hope that my prior actions on behalf of the community will at least earn me a "wait and see" attitude on the part of the community as to whether the above turns out to be true! Thanks for reading, and good luck to us all in this, and the remaining Zope Adventures!

3 2

RE: [Zope] Traceback?
by Marcus Collins 29 May '00

29 May '00

> -----Original Message----- > From: Chris Withers [mailto:chrisw@nipltd.com] > Sent: 29 May 2000 14:01 > To: Martijn Pieters > Cc: Patrick J.M. Keane; zope(a)zope.org > Subject: Re: [Zope] Traceback? > > Martijn Pieters wrote: > > If you switch debug mode off, tracebacks will be included > > in error messages as HTML comments, thus rendering them > > invisible from the unsuspecting site visitor. > > Is that true even if you override standard_error_message? I believe so, and empiracally this appears to be the case. From HTTPResponse.py: def _traceback(self,t,v,tb): tb=self.format_exception(t,v,tb,200) tb=join(tb,'\n') tb=self.quoteHTML(tb) if self.debug_mode: _tbopen, _tbclose = '<PRE>', '</PRE>' else: _tbopen, _tbclose = '' return "\n%s\n%s\n%s" % (_tbopen, tb, _tbclose) which is appended to the body of the error message when an exception occurs. hth, -- Marcus

3 2

FYI: Recap of Perl For Zope thread
by Paul Everitt 29 May '00

29 May '00

This has been a wonderful and useful discussion. I'd like to summarize some of the points made, and on the next post, give some more information about what we're trying to accomplish. First, I'm surprised nobody flamed me for the stupid linewrapping. All I can say: Outlook. :^) On to the summary... ----- My main man J. Atwood led things off with, "Why not Java?" Denis Frere floated the worry that Perl would take over Zope. Heiko brought up an oft-repeated statement: I intentionally left Perl, why is it following me around? Andrew Kenneth Milton pointed out this could increase the gravity of Zope, plus be a good re-education center for Perl folks. :^) Ragnar pointed out: "I don't mind if it is _possible_ to use external perl functions as long as I don't _have_to_." John Chandler helped put this in perspective: "whether or not people like the language, it does have a lot of existing support and developers who might find this a useful way to get involved in exploring the wonderful world of Zope." J. Atwood summed up the sentiments of a lot of people: "if you introduce Perl into Zope it would be like throwing a pair of red socks in your white wash, we all go pink." Rik brought up the looming issue: "Agreed, but the need for a Zope best practices guidelines (when to use what, and when _not_ to use it) is growing with every new language/method ;-)". I say "looming" becuase it highlights what Patrick said (see below). Martijn Faassen, head zope-xml guy, chipped in: "[as long as] I can't *see* the Perl if I don't want to see it". Chris McDonough said: "Honestly I'm sort of surprised that there is such a strong reaction to this." Brian Lloyd wrote: "You certainly wouldn't have to worry about Perl unless you choose to." Unlike what _I_ usually say, when Brian talks it's accurate. :^) Oleg Broytmann wrote: "A year ago I resigned from a web development company because they forced me to write Perl." Steve Alexander said, regarding the thought of stumbling across Perl in Zope: "When people can write their site half in Perl, I could well be stuck." Very good point. John Chandler wrote: "I'm personally looking forward to being able to use Perl with Zope, so long as the Perl support is implemented in a Zope-consistent fashion." Kevin Dangoor wrote: "I was a little puzzled when I first read the announcement, but after reading the FAQ I think it sounds like a great idea!" Chris Withers replied: "Further from this, I think diversifying the language base to Python/Perl/XSLT/etc is bad. It means that for someone to be 'proficient in Zope' form a marketing or job hunting point of view, they also have to know Perl, XSLT, etc rather than just Python and DTML. It defocuses Zope from what it is." Oleg Broytmann said: " Very soon we'll be forced, 'cause most Products will be in Perl (yse, I've read the FAQ and saw "no Perl Products"; it's temporary, mark you)." J. Atwood said everything I could hope to say, so I'll quote it all: """ The head of my company here has a theory that all "techies" have a religion when it comes to tools/languages/application environments. To a certain degree he is right. I believe in Python. I use it, love it and live by it. I have faith that if I write something in Python I can come back to it in a day or a year and understand it in minutes. I am also a believer in Zope, first for its power but second because it uses Python. Zope will benefit from the Perl community just as it has with XML. I agree with some of the comments that I don't want to see Perl code floating around in my management screen but it would also be very powerful to have modules/products written in Perl and dealt with in DTML. There are tens of thousands of Perl programmers out there, just think of all the cool things they write (especially if they found a better tool). """ (See, triple quotes, you guys thought I was giving up on Python. :^) John Chandler wrote: "Even as a Perl fan, I agree and don't see the sense in placing Perl-style expressions in DTML." (Let's get rid of _all_ expr, that's my vote.) Chris Withers wrote: "Suddenly Zope is a total mess of perl and python and the whole community shifts onto something cleaner leaving DC high and dry and spoiling a perfect solution..." Brad Clements wrote:"The undisputed leader in programmer's narcotics on the east coast was the DC Gang, whose leader, master Zope, developed a bold plan for stealing clients from the Perl gang by secretly pushing Python through free code and a framework to hang it on." Andrew Kenneth Milton wrote: "I don't think I've ever seen paranoia and religious fervour mixed in quite the same way before. Anyone would think that people think that python is inadequate as a language." Chris McD wrote: "There are *lots* of smart Perl people, and personally I look forward to seeing some of them join the community." Ethan Freemen wrote: "Zope's problem domain is simply too wide to be addressed by anything but an all-inclusive approach." John Sutherland said: "If they want to open it to Perl/Java/ etc, more power to them, more products for us to use.." Roman Milner said: "...were I to want to find a different job now coding Zope - perl will be expected to be in my skill set." Bill Anderson said: "Even if it isn't done by DC, a large perl user base *will* come up with perl products. At which point DC will either be pressured into accepting them into thecore, or watching the branch become the dominant Zope." Michel Pelletier wrote: "We don't want these folks coming in here with their years of experience and thousands of lines of code and snub them." Kevin Dangoor mentioned: "It's a fact of web programming that there are lots of tools written in different languages." Tom Neff said: "My primary worry (if you're listening, Digicool) is that integrating the Python and Perl runtime environments on various platforms will lead to unexpected conflicts and performance problems." Eric Sink said: "Maybe it's about "scripting languages vs. Java"...I don't see this announcement as a major shift toward Perl on the part of the Zope developers." In fact, Eric also gets a triple quoted section: """ Let's suppose for a moment that Zope's ambitions are much bigger than we think, and that its commitment to purity is slightly lower than we think. In other words, let's just suppose that Zope really wants to be 'The Scripting-Language Application Server'. If so, then why should it not invite the [enormous] Perl crowd into its community? """ Roman Milner said: "Perhaps this is a disadvantage to the DC company-owned open-source project model. They will make bad decisions based on potential profit." Hannu Krosing said:"See for example PostgreSQL - it has C, SQL, PL/SQL, TCL, Perl, Ruby and soon python as its server-side programming languages, with no real argument about weather to include yet another language." Dieter Maurer wrote: "There are many Internet Sites using lots of Perl. If you allow them to use Zope and retain lots of their Perl infrastructure, you have a much better chance to convert them to Zope...This, e.g., is the case with the company, I work for." Ken Manheimer wrote: "I also think these objections are contrary to one of the principle reasons that python itself is so attractive - it's a glue language, after all." Daryl Tester says two things that bear mention: "I think there is a significant proportion of Python programmers who are Perl refugees (funny, you don't hear much about the flip-side of that equation), so this announcement was bound to rub a few raw nerves the wrong way (if you pardon the metaphor mix)...But I figure DC are pretty smart guys...so let's give them the benefit of the doubt." Roman Milner gets another mention: "I think that anyone who wants to claim Zope expertise will need to know and be willing to code in perl." Michael Oas wrote: "Actually, I'd like to see Zope interface with "more" languages (Java, C++ etc.)...The fact that we can leverage Perl resources now and port them over time (if it even makes sense to do so) is beneficial." Anthony Baxter wrote: "After thinking about it some more, I'm still a bit concerned, but I also think that this will be a nice bit of bait to use when hooking in new developers. If it including building Products in Perl, I'd be a bit more concerned..." Patrick Phalen said: "Had the documentation been brought up to par some time ago (say around the time of the 2.0 release), then I doubt that the Zope community would now feel any need or desire to embrace the Perl (or any other) user community in order to gain support for Zope." Kevin Dangoor wrote: "Zope is a very powerful framework that is already fairly language agnostic." Ethan Freemen wrote: "If someone has a substantial investment in Perl, and they want to keep that as an External Method in order transition to Zope, then they should be able to. It has been a barrier to the adoption of Zope more than once, I would imagine." Sin Hang Kin wrote: "Zope needed to clean up before it goes too bad. Zope is powerful, but is already too difficult for beginner to learn." (Very, very good point!) Bill Anderson brought up: "I believe that at least a good portion of the reason for the negative reaction is not just perl, but also due to this 'community' we hypothetically acquire." Tom Neff replied: "The fallacy here is simply that Zope is adding a language, not a newsgroup." Karl Anderson wrote: "It's also an even more excellent time to be a sklled Zopista looking for a job. Find a good place looking to start a Zope project, build them a site, & you'll be deciding whether to use Perl products or not." Graham Chiu brought up: "What I would like to see first is support for Rebol." ...and I'm caught up! That only took 3 hours! :^) --Paul Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/ -----------------------------------------

2 1

A similar issue with Perl for Zope
by Michel Pelletier 29 May '00

29 May '00

Jon Udell wrote: > > BTW, there is essentially no difference between VBScript, JavaScript, > PerlScript, or PythonScript when used at this level. All can make the > same CreateObject call, and diddle the controlled app's object model in > the same ways. It ends up not being a language issue at all, but more a > case of, as I said, what the heck is that object model anyway, and then > why doesn't it behave as expected? This is such a good point I wanted to share it with the Zope community as well. The language issue is minor to the need for a definate object model with clear interfaces. It shouldn't matter if the core of Zope is written in Python or FORTH, from your perspective and the perspective of your language the model and interfaces should be well definded. -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral

2 1

RE: [Zope] Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
by Paul Everitt 29 May '00

29 May '00

Roman wrote: > Perhaps this is a disadvantage to the DC company-owned open-source > project model. They will make bad decisions based on potential > profit. I wanted to address this specifically. This is, in the abstract, a legitimate concern that comes up repeatedly about Netscape/Mozilla. Obviously that kind of model has some tremendous benefits, namely paid resources and clarity of vision. At the same time, though, there is the potential for abuse. As the person that made the decision, I can at least testify that no ulterior motives were behind it. Still, Zope is a community thing, and we here at DC need our heads bopped on a regular basis, lest we ever forget it. Consider our heads bopped. :^) --Paul

2 1

Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
by Roman Milner 29 May '00

29 May '00

Here is why I'm bummed about this. Like other people who have posted - after years of coding perl for money, I have vowed never to do it again. (I find that it produces encourages unmaintainable code.) Also, I think my main marketable skill now is Zope. So, were I to want to find a different job now coding Zope - perl will be expected to be in my skill set. Other companies using zope will almost certainly have perl methods laying around that need to be maintained. So, basically, in order to find a job using zope - I'll have to relearn, and code in perl at that job. So, I believe this is enough reason for me to start considering other web technologies for me, and my company. ^Roman >>>>> "PE" == Paul Everitt <Paul(a)digicool.com> writes: PE> Howdy gang. Below is an announcement that we'll start PE> distributing over the next 24 hours. I wanted to let you PE> folks see it first. In summary: Perl Methods. PE> This isn't a press release, which we'll be doing in the run-up PE> to the O'Reilly Open Source conference in July, when the code PE> is closer to being available. PE> ----------- PE> Digital Creations, creators of the Open Source Zope PE> application server, announced today that it is teaming with PE> ActiveState, a leading provider of Internet programming PE> software, to make Perl a scripting language for Zope. PE> Perl is the predominant scripting language for Internet PE> applications and is a key success story for the Open Source PE> software movement. Zope is written in Python, the fastest PE> growing Open Source scripting language. PE> "It is clear that the strength of Zope realizes the future PE> architecture of the Web," says Paul Everitt, CEO of Digital PE> Creations. "This dynamic architecture, and the people working PE> with it, are a fantastic match for scripting languages. Thus PE> it is natural that Digital Creations would team with PE> ActiveState to make Perl a scripting language for Zope." PE> "Zope is a powerful content management system that we use PE> internally," said Dick Hardt, CEO of ActiveState. "By adding PE> the power of Perl to Zope, we will be able to leverage all the PE> existing Perl technology that we have as well as bring the PE> worlds of Python and Perl closer together." PE> Under this agreement, ActiveState will get Python and Perl to PE> run in the same application. More specifically, Perl PE> programmers can code critical pieces of business logic in Zope PE> solutions. PE> "The Perl for Zope project brings the worlds of the two most PE> important open source programming languages together," stated PE> Gisle Aas, Senior Developer, ActiveState. "Python programmers PE> will be able to directly take advantage of the large PE> collection of reusable Perl program modules, like DBI, found PE> on CPAN. Perl programmers will be able to program and PE> customize the Zope web application server using their favorite PE> language." PE> The initial developer release of Perl For Zope will coincide PE> with the O'Reilly Open Source Software Convention in July PE> 2000. For more information on the project, please visit the PE> Perl For Zope project page at PE> http://www.zope.org/Wikis/zope-perl/. PE> Contact Information PE> For Digital Creations, contact Paul Everitt, PE> paul(a)digicool.com, 540.371.6909x102. For ActiveState, contact PE> Lori Pike, lorip(a)activestate.com, 604.713.8433. PE> --Paul PE> Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909 PE> ----------------------------------------- The Open Source Zope PE> application server http://www.zope.org/ PE> ----------------------------------------- PE> _______________________________________________ Zope-Announce PE> maillist - Zope-Announce(a)zope.org PE> http://lists.zope.org/mailman/listinfo/zope-announce No cross PE> posts or HTML encoding! (Related lists - Users: PE> http://lists.zope.org/mailman/listinfo/zope Developer: PE> http://lists.zope.org/mailman/listinfo/zope-dev )

7 8

Why Perl for Zope is good
by Itamar Shtull-Trauring 29 May '00

29 May '00

1. Zope is complicated 2. Adding Perl to Zope makes it more complicated 3. Most of us here have some Zope knowledge 4. All the Perl programmers who will flock to Zope won't have this knowledge 5. Zope with Perl will be even more popular RESULT: We can get rich as Zope consultants. All the arguments I've heard here are rather fanciful - Zope will be less stable, Zope will be corrupted, the majority of Products will be written in Perl and destroy Zope. This is ridiculous. It's like saying DC should take out DTML cause people might try to write business-logic in it (which I have done, but I know better now.) Perl is better than Python in some things (a lot more available modules, for one thing), and Python is better than Perl in most other things. For example, my co-worker Noa once ported the Perl module for making english words plural to Python - if we had Perl Methods we could simply use that and not waste time porting it. And again - You don't have to use it (TM). And if the thought of maintaining someone else's Perl code is so horrible, think about maintaining someone else's DTML code. Like, I once tried to write a workflow system in DTML :) -- Itamar S.T. itamar(a)maxnm.com

2 1