Re: Transaction Processing
Stephen Adkins writes: I will be downloading bOP and evaluating making P5EE work with it. I don't think many people are interested in a bOP adapter. Rob: Does this seem like a good idea, and would you and bivio Software Artisans, Inc. look kindly on such a development? We always like people using bOP. It makes it stronger better faster... (Presumably this code base is actively developed, with lots of vision and direction for where it is going in the future.) We use bOP daily in our projects. Think of us as the arsDigita for the new millennium. ;-) Are there other mature transaction processing packages for Perl that I should be evaluating? I think we need a definition of transaction processing. Anything that uses mod_perl and a database is processing transactions. There are a zillion platforms, most of which are not publicly available. Just yesterday I was talking with a company which uses Perl, PHP, and Oracle/PL/SQL. They have an architecture which has evolved over time and certainly suits their needs. They process well over 100,000 transactions a day. The question you need to ask is: What would make this random company choose P5EE over their own infrastructure? bOP has been on the market for almost a year. I don't know anybody who is using it for real work other than us. I have conversed with a number of people about bOP. I have lectured at my local university. If you type OLTP into google, our site is listed first. My point is that even with a lot of code, some documentation, and some marketing, it is really hard to sell in the enterprise. I think this is the point Matt and others are trying to make, too. Rob
Re: Transaction Processing
At 03:02 PM 5/15/2002 -0600, Rob Nagler wrote: Stephen Adkins writes: I will be downloading bOP and evaluating making P5EE work with it. I don't think many people are interested in a bOP adapter. Do you mean people on this list? Why would that be? or people you have talked to over the last year? You had some comments/criticisms of P5EEx::Blue (all comments welcomed). Should we consider bOP as your entry as though it were P5EEx::Bivio? Does it address the issues you commented on? Are there features you would like to highlight such that the P5EE would benefit by incorporating them? Stephen
Re: Transaction Processing
Stephen Adkins writes: I don't think many people are interested in a bOP adapter. Do you mean people on this list? Why would that be? or people you have talked to over the last year? No one uses bOP except us, and bOP is all we need. If we needed more, we'd add it. You might want to look at bOP to see a problem-oriented solution rather than say J2EE which is a solution-oriented problem. Compare our implementation of the bOP PetShop with J2EE's Blue Print Pet Store. Should we consider bOP as your entry as though it were P5EEx::Bivio? I don't think we should call it P5EE. It's not about distributed systems (been there, done that). In concert with Apache and an RDBMS, it replaces what people used to use to generate 3270 applications. However, we have no equivalent to EJB, JMS, RMI, SNMP, etc. Something needs to manage Apache and the RDBMS. Does it address the issues you commented on? No. Are there features you would like to highlight such that the P5EE would benefit by incorporating them? There are lots of features, but they support each other. For example, almost all classes derive from Bivio::UI::WidgetValueSource. This allows the object to be referenced by widgets. Our widgets request data through the interface get_widget_value, which has evolved to support widgets and values in a nifty way. However, there's no point in adopting this feature unless you also adopt the way widgets work. We've talked about bOP on this list before. It doesn't align with the general goals of P5EE imo. We pitch bOP as a declarative application framework. P5EE seems to be going after distributed systems like J2EE. Rob
