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
