Re: Sun Is Losing Its Way
On Fri, Dec 13, 2002 at 06:42:36PM +0200, mohammad nabil wrote: support Sun, Open Source, and all good manufacturar in our nice world :) Do you just not grasp that Sun's rigid control of Java is the antithesis of Open Source, and _especially_ the Apache philosophy? Try forking the Java codebase sometime. See how fast it takes Sun's lawyers to find you. Want to port Java to a new platform? Get special permission from Sun, and don't plan on having public CVS (see the FreeBSD experience). There's nothing open about that. Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Differences between Structs and Turbine ???
On Tue, Oct 08, 2002 at 03:03:37PM -0700, Jon Scott Stevens wrote: Interestingly enough, I did write a quick little framework that works very similar to Turbine and has the same concept of users/roles/permissions. =) Well, if you want an MVC framework, someone did a port of Maverick to PHP: http://amb.sourceforge.net/ :-P Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: You guys are so funny.
Hear hear! (But go emacs! ;-) B... vi rules! Ed is the standard text editor. http://www.gnu.org/fun/jokes/ed.msg.html :-) Jeff Schnitzer [EMAIL PROTECTED] Yes, I was reading alt.slack in '91 :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Database Subproject Discussion : creation of DBCommons ?
How about tweaking db enough so that it both pronounces better and has less explicit meaning? I like: dub.apache.org Let someone else figure out acronym meaning later :-) Jeff Schnitzer [EMAIL PROTECTED] How many millions of dollars did Andersen spend for the name Accenture? Sounds like some sort of meat seasoning. No MSG! -Original Message- From: Jim Seach [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 3:42 PM To: Jakarta General List Subject: Re: Database Subproject Discussion : creation of DBCommons ? I don't have a problem with db, but if that is associated too strongly with relational databases, how about datamanagement or dm? Another option would be just data. Jim Seach -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: You guys are so funny.
Sorry, didn't intend to throw the whole mail at you. I haven't been around as long as you (probably a little over a year), but this is one of my favorite lists. It's far more entertaining than television :-) Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 10:00 AM To: Jakarta General List Subject: RE: You guys are so funny. Hey Jeff, I can agree with all you say but I don't understand why you throw this on my direction. I have been defending the existence of competing projects since the Tomcat 3.3 versus Tomcat 4 wars until my most recent posts at the commons-dev list. Maybe you do not follow the same lists I do. Maybe not for long enough. If you read Jon's postings along this thread, you will also be better informed about whom has a thin skin problem. Have fun, Paulo Gaspar -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 11:59 AM To: Jakarta General List Subject: RE: You guys are so funny. From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Of course that from the way Jon talks about me you can tell that I do not always agree with him - Jon seems to only be friendly to those that agree with him. For the record, I've even committed the cardinal sin of creating a MVC webapp framework which is not Turbine (http://mav.sourceforge.net), and Jon is still pretty friendly to me :-) You guys all need to lighten up. It's not like this is a workplace where everyone is competing for promotions or something. How this social game plays out isn't going to affect your paycheck or the people who hang out with you or whether or not you're going to get laid this weekend. A fair amount of banter is healthy in any community. Poking fun at each other, lighthearted insults, competition, and yes conflict are a standard part of any sitcom production. Sure, there's a time for we all love each other mushy-type stuff but if it was like that all the time it would get boring really damn fast. It is my observation that Apache works because of thick skins, not because of peace, love, and happiness vibes. There's nothing wrong with a limited number of competing projects under one roof. It's probably even a good idea. It's not like Maven and Centipede are competing implementations of the same API - this is pretty much a research field, and it's impossible to categorically predict at this point whether it is better to extend or generate the Gump descriptors, or to use XSLT or DVSL, etc. Until the science becomes engineering, this mad driving need (among some) to merge merge merge is a pathology. Let it be. Use the software you like. Write the software you like. Berate people over the truly important things, like choice of text editor :-) Jeff Schnitzer [EMAIL PROTECTED] ed is the *standard* text editor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: You guys are so funny.
Dude, do you really need to respond to *every single* piece of mail? Jeff -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 5:51 PM To: Jakarta General List Subject: Re: You guys are so funny. [part bazillion deleted] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: You guys are so funny.
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] I really wonder why it is that all one has to do is say Microsoft on any Apache thread and they get 100 responses. I wonder if it works that way on whatever-microsoft-related-lists are out there. Someone needs to update Ellison's Law, s/Hitler/Microsoft :-) Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Uhhh: Outer joins? Fetch data across multiple objects? Aggregation queries? Torque is an O/R mapping framework, with all of the inherent limitations of trying to make relational data look like objects. Crossdb is a database-independent abstraction of SQL (not JDBC, that's an important distinction!). These are not competitive facilities; in fact they should be highly complementary. At the moment, Torque's extremely limited Criteria object has a tough time with simple conditions like WHERE bob 5 and bob 10. Subqueries and joins are hopeless. Crossdb is what Torque desperately needs - a good database-independent way of specifying sophisticated conditions. The WhereClause in Crossdb could be substituted wholesale for Criteria. And for those of us that have to query our databases and obtain results which do not map 1-to-1 with a single object (such as anything that involves a group by or an outer join), we can bypass Torque and still have database independence. I think both Torque and Crossdb (if it has the community) are very much needed as top-level Jakarta projects. They are both bread-and-butter server development tools. Putting Crossdb under Torque makes about as much sense as putting Torque under Turbine. Oh, and Jon, the comparison with ECS is not very good. Web pages are a creative endeavor, whereas SQL statements are short and built by hard-core programmers. Also, simple HTML does not suffer from the problem of every web browser on the planet requiring a slightly different syntax for putting columns in a table... Velocity might be less useful if a separate template had to be written for every single web browser. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Comments on the commons-logging API
From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] Yes, the defining advantage to the commons-logging API that I see is that it allows users to adopt a single logging implementation, which confers real What needs to be appended to that statement is ...if everyone codes to the commons-logging API. The exact same statement can be reconstructed using Log4J API and it is equally true. If everyone uses commons-logging, then only one logger must be configured. If everyone uses Log4J, then only one logger must be configured. If third-party software is using different loggers, then you have to configure multiple loggers no matter what API your code uses. It seems to me that the commons-logging API just adds Yet Another Logging API... especially when someone gets the bright idea to make a native implementation of the API for performance reasons. At least with Turbine, Struts, (Maverick :-), etc, there are some fundamentally different approaches to the problem of how to publish a web application. Logging doesn't seem that complicated. The massive duplication of this basic feature in the Jakarta codebase is silly, and trying to build an abstraction layer on top of it seems even sillier. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Micro JakartaOne
From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Also, I'm still willing to show people the club, even if we aren't doing anything... Definitely! Sorry to hear that a big organized shindig won't happen; a small disorganized shindig would be fine too though :-) Jeff I just started a new contract, so I'm waaay too overloaded to help organize. Sorry. But I'll help contribute to the revelry :-( -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] ASL vs. GPL page: is this okay?
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] The question is: How do you want to spend your time? Possible answers: 1 Fighting an unwinnable (defined as the argument having a logical conclusion where one side overwhelmingly wins) religious war with the GNU hordes (hirds? hurds? ;-) ). . . 2 Coding and documenting There are quite a few people around here who spent an awful lot of time working on #2 because they weren't successful at #1. If the WebMacro folks hadn't stuck to the GPL, it would not have been necessary to reinvent it as Velocity. IMHO, evangelizing the APL is an important goal of the Apache project precisely because it reduces the amount of (re)coding and (re)documenting we will ultimately have to do. I applaud Jeff's document, and I would love to see the finished version linked off the main Jakarta page (as well as www.apache.org). Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Java is dead... but it could still be saved!
From: Scott Sanders [mailto:[EMAIL PROTECTED]] Stefano, you are right on the mark as usual. As soon as a java2c# porting tool is available, the hordes will probably be moving on... Actually, forget a porting tool. I want an open-source version of something like this: http://msdn.microsoft.com/visualj/jsharp/beta.asp Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: J2EE considered harmful
From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]] Are you just talking about creating a new language, or what? What is your idea? I cannot tell. That's a good question, and ultimately one which would be determined by the constraints of the technology. Prototyping would probably involve using an existing language and platform, and maybe we would ultimately discover that it is possible to build a system like this on top of a JVM (or CLR). My suspicion is that it is not, and may be undesirable for legal reasons anyways. The later part of my diatribe was a hastily phrased way of approaching this subject: Unless you want to go back to the dark ages of C++, the future is shaping up to look like a choice between writing for the Sun platform or the Microsoft platform. This does not make me comfortable, especially considering that Sun's approach to Java so far has been *wholly* anathema to the principals of Open Source. At least Microsoft has submitted C# and the CLI to ECMA. Quoth Jon: *WAKE UP PEOPLE* I am tantalized by the idea of a third choice: the Apache platform. I propose a discussion of just what that might be. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: J2EE considered harmful
From: James Strachan [mailto:[EMAIL PROTECTED]] (*) One thing I've noticed with SOAP is that developers from the different camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The web/MOM guys tend to think of SOAP as a universal message format so the same structured message can pass across many transports http/email/news/MOM to connect anything to anything in a language, platform and transport neutral way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its CORBA but using XML rather than IIOP and go off building stubs/proxies/IDL compilers etc just like with EJB/CORBA. I don't think web/MOM/SOAP and CORBA/EJB are comparable technologies. The former are communication protocols, and the latter are (primarily) programming APIs. To emphasize this point, in the .NET universe, the remote invocation protocols are pluggable... you can write to their distributed object model API and use SOAP, DCE-RPC, IIOP, JRMP, SMTP, or just about anything else you can dream up. For that matter, there is no reason why you couldn't create an EJB container which used HTTP/SOAP as the transport protocol. I would compare EJB to the programming API for your SOAP or MOM implementation. Theoretically EJB (or any distributed object model) provides a high-level abstraction so you don't need to fuss with the complexity of all the protocols and mechanisms underneath. Of course, the tradeoff is flexibility and performance. The problem with EJB, IMHO, is that it has merely replaced the complexity of the underlying system with the even greater complexity of the EJB system, and still significantly inhibits your ability to write well-performing applications. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
From: Steve Downey [mailto:[EMAIL PROTECTED]] Most objects don't work if they are made distributed without careful consideration. I wonder if that has to be the case. Right now, our distributed object containers are blissfully stupid. We (humans) can point at any individual class or interface and say remote thyself! but that's as far as it goes. The container just does what we programmers tell it to. Just like me, a hypothetical smart container could make some pretty educated guesses about where and when a set of existing objects should be remoted. Furthermore, it could automatically learn, over time, not only where the best boundaries are, but what are the best situations to perform the remoting/migration. Instead of deciding which classes should be remote, a smart container could decide which *objects* should be remote. And it could learn the answers by watching object behavior over time. Of course, architecture would still have a big effect on performance - but it does already, even in a single-machine environment. We don't hand-optimize our assembly anymore, and suspect that eventually we won't be hand-optimizing our distributed systems, either. JADE and Mobile Agents are not quite what I have in mind. The agent concept is very thread-centric, whereas this idea is object-centric. It sounds like EOB and AltRMI are closer to the mark. I'm going to have to take a long look, and maybe try to restart this discussion on one of their mailing lists :-) Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: J2EE considered harmful
Amusingly enough, I've been considering writing an article with this exact same title. I've implemented two medium-sized systems using EJBs (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've been haunting the ejb-interest list for more than a year. I was never ecstatic about the technology, but now I'm starting to feel downright disillusioned with it. This is not coming from someone stumbling around with the technology. The first thing I did was read Richard Monson-Haefel's book cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only implementation. I've got most of the 2.0 spec memorized. I have no trouble writing the deployment descriptors by hand. The problem is, even after more than a year of this, I still find that writing software using EJBs is a steady progress of fighting the technology to make it do what you want. It shouldn't be like this. Having to write three or four different classes, plus an elaborate deployment descriptor for each object slows things down a bit. Tools like xdoclet help, but it's still a complicated and painful process to refactor anything. Basic software design patterns are agonizing or impossible to implement. Observable? Time to learn JMS and Message-Driven Beans. Singleton? Not in the framework... you have to set up an external RMI server. Presistance in the EJBland is a disappointment. Even with EJB 2.0, entity beans are not remotely mature. There is no support for relationship attributes or automatically generated primary keys. The query language is constrictive, offering no support for ordering, aggregation functions, or retrieving data which spans more than a single class. After 20+ years of research and advancement in RDBMS technology, this is a colossal step backwards, and the consequence is that entity beans radically underperform systems with more direct database access. I find that I must constantly sidestep the container with direct JDBC in order to meet performance or feature requirements, and it sounds like this is a common problem. Overall, my feeling is that Sun tried to cram too many disparate technologies into a single API. EJB! It's a distributed object model, transaction model, security model, persistence model, component model, message queue, desert topping, and floor wax all rolled into one! Some of it makes sense, but some of it (especially persistence) doesn't. I'm surprised that people can build large applications with EJB. My guess is that it's probably very effective for one particular class of problem - ecommerce apps. I'm sure it's no accident that all the examples in the spec are Order, LineItem, etc. Unfortunately, this doesn't help me, or any of the rest of the people who are working on applications that are actually interesting. And my guess is that since ecommerce is 90% of the market for expensive app servers, Sun doesn't really care. Ok, enough whining. What to do about it? I really like the idea of an Apache community building a truly free competitor to J2EE. I don't like being tied to technologies owned by a single company, so I'm already pretty nervous by the stranglehold that Sun has on Java and (especially) J2EE. But it's not enough to build a marginal improvement over the existing system, even with Apache's mindshare. Besides, who wants to copy a mediocre idea? :-) I've been giving a lot of thought to distributed object models lately. I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a lot of the same. Since networks are getting so fast these days, I'm starting to really wonder what it would be like to have a model in which: * All objects are inherently remotable. * Objects transparently migrate for efficiency. I can think of many interesting, fairly revolutionary consequences of such a system and I'd love to discuss them. Ultimately, if such a system ever made it out of research and into prototype, it could challenge both Java and .NET, and possibly stave off the coming hegemony of the Sun/Microsoft duopoly. (Yeah, yeah, there will always be people who enjoy working on nonvirtual machines, but they're crazy :-) Does anyone think some variant of this idea to be worth pursuing? Or is everyone wedded to the idea of working on the proprietary Sun platform known as Java? Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: commentary by Linus Torvalds
There seems to be some debate about whether or not that is really the case. At least it has Richard Monson-Haefel (the author of the O'Reilly EJB book) and Floyd Marinescu (from TheServerSide.com) confused, from this post to ejb-interest a couple months ago: http://www.mail-archive.com/ejb-interest@java.sun.com/msg19000.html My take: While section 10.5.2 maked it look like you can leave the PK unset in ejbCreate and the container will automatically generate a key for you, the spec doesn't (that I could find) explicitly specify anywhere that this is in fact the case. The wording of section 10.5.2 could be explained by the use of deferred key types, which could conceivably provide an akward way of making autogenerated PKs, but only in wholly container-dependent manner. In the 1.1 spec, it was necessary to set the PK explicitly in ejbCreate, so some explanation would seem to be in order... blah. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Richard Kirby [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 11:54 PM To: Jakarta General List Subject: RE: commentary by Linus Torvalds EJB2 does allow for automatic generation of freaking primary keys - unless I misunderstood you. Thats one of the points of having ejbCreate and ejbPostCreate. Mind you, I personally feel that Torque offers far more than EJB, if you are building from scratch and don't have legacy systems. Richard [EMAIL PROTECTED] -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: 06 December 2001 07:28 To: Jakarta General List Subject: RE: commentary by Linus Torvalds cut As a case in point, I would like to point out EJB CMP as an example of design-driven technology which may very well look really stupid in another few years, especially given its atrociously slow mutation rate. If anyone who was writing this crap (the spec) was actually *using* it, it would probably allow for automatic generation of freaking primary keys... Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: commentary by Linus Torvalds
And for an example of a dead company whose products are gone too, how about Ashton-Tate (anyone remember dBase?). I liked Linus' comments. They essentially echo the arguments for XP, that software should be evolved rather than Designed (captial-D). Even though he was (apparently) talking about Solaris when critisizing Sun, the same argument indicts the acolytes of the Java Community Process as well. As a case in point, I would like to point out EJB CMP as an example of design-driven technology which may very well look really stupid in another few years, especially given its atrociously slow mutation rate. If anyone who was writing this crap (the spec) was actually *using* it, it would probably allow for automatic generation of freaking primary keys... Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Neville Burnell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 2:22 PM To: 'Jakarta General List' Subject: RE: commentary by Linus Torvalds their products are still around, still evolving, but those corporations are long gone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 4 December 2001 10:55 AM To: Jakarta General List Subject: Re: commentary by Linus Torvalds Neville Burnell [EMAIL PROTECTED] writes: anyone remember Lotus Developments and WordPerfect Corporation ... they had billions in the bank too snip Lotus == IBM WordPerfect == Corel. Still around... just different names :) -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/ Yoink dot adios backslash loosers! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Cross site scripting
Since CSS vulnerabilities are due to the nature of html presentation, it seems to me that the presentation layer is clearly the place to fix it. Storing encoded data is a bad idea, IMHO, because: You've got to somehow ensure that all input data is channeled through your encoder. Sure, this may be easy for web forms, but what about direct updates or imports to the database? What happens when you try to use your data in a different presentation technology such as a Swing or console app? Trying to de-escape the data everwhere you use it would suck. You can escape data for HTML 4.0 and store it... but what about years from now when HTML 8.0 rolls around and there are new things to escape, or old things that should be escaped differently? Reprocess your whole database? I think you should always store the data model in as pure a form as possible, and let any particular presentation layer make sure that data behaves well. HTML output escaping is pretty computationally trivial, so performance doesn't seem like much of an issue. Mixing presentation-specific encoding into the data model, on the other hand, is setting up for future peril :-) Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 21, 2001 1:20 PM To: Jakarta General List Subject: RE: Cross site scripting Actually I was busy, what I really wanted to say was that I agree with every one of the points you make, but still stick to my prefrence for escaping on the way in, but ok lets say only where practical. I've been involved myself in a project where we had to accept input of script and prepare output of it for display or execution. And there are a number of other legitimate uses for some of the techniques which come under the umbrella of CSS. The only truly compatible answer is to delegate to the application designer full responsibility for this task. Hence, of course, the requirement for a small API to help her/him do the dull hard work. (which I'm right behind) d. -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 21, 2001 6:57 PM To: Jakarta General List Subject: RE: Cross site scripting Ok, you're right! d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Cross site scripting
From: Jon Stevens [mailto:[EMAIL PROTECTED]] Does anyone have code they want to contribute to get this started? How are you currently dealing with these issues? What is your favorite way to escape things? Do you filter/escape all content or only some content? Etc. In the world of XSL, I think these issues are already taken care of. At least in a domified approach, the data only ever gets translated into XML as a final step, and the XSL processor automatically escapes anything that will have XML or HTML meaning. In the world of JSP, I would expect that bean-access custom tags would do this escaping. Do the Struts taglibs or any of the jakarta taglibs take care of this? In the world of Velocity... is there a switch that can be set on Velocity to automatically escape anything with XML/HTML meaning? Should there be? Of course, all these effectively disable _all_ htmlish tags, which might not be wholly desirable... still, it seems to me that that the best approach is to escape everything and then selectively translate *back* only the tags you want working (like b). Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Business-Oriented XML
Uhhh, let me tell you what comes and goes much more often than platform languages: scripting languages. You're proposing to exchange a widely understood, highly evolved programming language with a homebrewed scripting language that has a very high likelihood of becoming nothing more than a blurb in the jakarta-general list archives in a few years. The mere fact that your script has an XML form doesn't inherently give it staying power; hell, I could pretty easily define an XML form for Java grammar if I wanted to. Java is obviously not the endpoint of language design, but it does happen to be about as good as we have come up with so far. It's a great tool for defining business logic because it's flexible, fast (enough), and very widely understood. It has sufficient critical mass that it will be around long after you have gotten tired of working on BOX. So I don't buy the argument that BOX buys you longevity - the world of software is littered with dead scripting languages for dead tools. The problem I have with the BOX concept is that it is a step *backwards* from all the progress we have been making towards three-tiered architectures. The idea of a new scripting language which abstracts the writing of business logic in some useful way is not bad. The idea of binding it tightly to an HTML publishing framework is *terrible*. You talk about how important it is to separate business logic from presentation, yet you seem to have missed the primary *reason* for this separation - so that the business layer can live on long after any particular presentation technology is dead and gone. The point is that business logic *can* be reused in a Swing client, or as a SOAP service, or as part of some sort of XML messaging system, or with the Microsoft Telepathy Mouse, or whatever else comes along. Tying your business logic to HTML or HTTP isn't any better than embedding it in JSP pages. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Dave Jarvis [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 17, 2001 11:08 AM To: Jakarta General List Subject: Re: Business-Oriented XML Hi, Jeff. I'm with Jon here: Why the heck would you want to do this? See previous reply. In addition, languages come and go. Remember when TurboPascal was hot? QuickBASIC? C and C++? Perl? PHP? What happens in 5 years when another awesome language makes an appearance and everyone forgets Java? Legacy code, I believe is the term. COBOL, FORTRAN, Smalltalk, etc. Tying yourself to a language isn't a viable long-term strategy. I love Java, don't get me wrong. But don't fool yourself into thinking it's going to be around forever. ;-) (This isn't flame bait; I'm using history and nearly 20 years development experience as a guide.) XML, on the other hand, is a technology with staying power and a history that extends back into the late 1960s! Another reason is that you can write more efficiently in a new language. I've found that BOX source is typically 5 to 30 percent smaller than equivalent Java. It has an extremely tight focus on basic business logic. for defining business logic. Why? It's trivial to define such logic in Java, and doing so avoids the limitations of your script (whatever they may be). The only limits are those imposed by the processing engine's implementation language. (Currently Java, but could be C, C++, Perl, etc.) Again, coupling yourself to Java (or any language for that matter) is not a good thing from a long-term perspective. What if you wanted to use a one-way hash on the passwords? What if user I had a similar problem already. The solution: var name=hashKey expr=generateHashKey( $parameter, $parameter2, $parameter3 )/ So long as generatePasswordHash is available to the system (neither defined nor imposed), it'll work. information was stored in EJBs or LDAP? What if you wanted to use the standard J2EE authentication and role-based security system? Can your script handle this? This can be solved in either of two ways: 1) Set up a small (internal) server that uses an XML-based protocol for information exchange. 2) Write a wrapper function to extract the information you want (e.g., generateHashKey). You can use whatever scheme you would like to test the password, limited only by your ability to express the behavior in Java. Furthermore, it if test=!checkPassword( $password ) var name=Phase expr='badPassword'/ stop/ /if As before, not limited to a particular language. But you might as well use Java, because Java rocks. :-) this example, the yourHelper object). How would your system reuse business logic to build a Swing client? No -- but then again, that wasn't what it was designed to do. It is meant for e-commerce/web-based solutions (plus interacting with remote servers via XML, simple file I/O, and database laughter). Nearly all e-commerce sites do
RE: How times change !!
From: Alex Fernández [mailto:[EMAIL PROTECTED]] I wonder: when Microsoft announces things like those, do they even take it seriously (since everyone knows they'll cancel it later)? Do they hire people? Allocate time for the tasks using Project? Even draw a PowerPoint or two to show around? Actually, I think all of the products mentioned in the article materialized. The COM support in the MS JVM was (and still is) really cool. The IDE mentioned has several features that NetBeans still lacks (like syntax checking as-you-type and a startup time shorter than Ellison's droning speech at J1). Compared to VB or VC++, J++ was pretty nice. It (and the MS JVM) are pretty antiquated these days, but the products looked like they had a bright future before the Sun lawsuit pushed them into the development of .NET. Jeff - Suddely realizing that he said something polite about MS, and that the room got very, very quiet :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
