Hi Ian Excellent idea.
The one issue I'd like to revisit before we got too far down this road and create more work later. Could we embed more of the company/instance configuration information into the database. Right now quite a few of the configuration settings that are associated with a particular company are hard coded into files rather than being in the database. Some examples are the default currency, email connection settings, ups and usps connection details, etc. I think having the configuration settings defined in the database are needed to create a truly user friendly product. Remember when of every single little change of an PC's network configuration required a reboot. Furthermore, it will support the conglomerates where different divisions each have their own UPS or USPS account, credit card account, or e-mail templates. Thanks Daniel On Wed, 2007-01-03 at 22:44 -0800, Chris Howe wrote: > I've been reading the posts on this thread all day and > trying to refrain from bashing my head on the keyboard > thinking this topic was already answered definitively. > Apache Ofbiz does have an auto-installation script > and the only way to make it more automatic is to be > bound by GPLv2 that would occur by bundling Java JDK. > > However, this evening I had the opportunity to > reintroduce myself to a dear old friend....Webmin > (http://www.webmin.com/) And it dawned on me: > installation and installation are two different > things!! > > Looking at webmin, these are a collection of > completely geeked out tools that can be configured by > just about the average Joe (assuming the average Joe > knows what the project is supposed to do based on the > strange names that some projects program under). How > difficult would it to be to make entityengine.xml, > url.properties, general.properties, (heck every ofbiz > file for that matter) configurable through a web > interface? (Didn't the content component have this as > somewhat as a goal at some point?) If someone could > manufacturer a demo script on how to make this > available, I'm sure the community could complete it. > Any takers? > > --- Ian McNulty <[EMAIL PROTECTED]> wrote: > > > That sounds like good news. > > > > But I also understand where those who are against > > installers are coming > > from. > > > > There's no point in having an easy installation if > > subsequent > > implementation is not equally trouble free. At least > > at the moment the > > difficulty of the installation gives good warning of > > the condition of > > the road ahead! > > > > Imho an installer should be somewhere on the list, > > but not at the top of it. > > > > More important would be the presentation of a > > proposition or a package > > that users can easily understand. > > > > This does not necessarily mean a one-click > > installation. > > > > Think of the development of any technology you like. > > The motor car is as > > good an example as any. Early installations were > > tailor-made one-offs,. > > hand-built by experts, of value only to engineers, > > enthusiasts and the > > extremely rich. The interface varied with each > > installation. The > > accelerator on the steering wheel and the brake > > outside the drivers door > > for godsakes! Who thought that one would ever fly? > > It took years before > > the interface settled down and standardised around > > something even your > > grandmother could learn to drive. Years more to move > > beyond the > > proposition you could have any color you liked just > > as long as it was > > Windows - ehr, sorry - black! Years more before most > > drivers could be > > assured that they wouldn't have to - in the words of > > the old song - "get > > out and get under" every time they popped down the > > shops for a pint of milk. > > > > Everyone accepts that complex technology requires > > some kind of learning > > curve. And that, without proper maintenance, it will > > probably break down. > > > > But it wasn't until the training could be > > standardised, and maintenance > > became more a matter of a regular oil change than a > > regular engine > > rebuild, that the the motor car became a proposition > > that was easy to > > understand, and the technology could move out of the > > garage and onto the > > highway. > > > > The change this precipitated was so radical that, > > now, it's the > > proposition of life WITHOUT the motor car that most > > people would find > > difficult to understand! > > > > Ian > > > > > > > > Anil Patel wrote: > > > Regarding Installation, > > > We have experimented with Building Ubuntu 6.06 > > Live CD with Ofbiz. > > > Also it > > > installs to hard drive with Ubuntu. > > > > > > Anil > > > > > > On 1/3/07, Adrian Crum <[EMAIL PROTECTED]> wrote: > > >> > > >> Some time ago BJ Freeman had suggested an > > installation wizard that would > > >> walk > > >> users through the installation process. Something > > along that line > > >> packaged > > >> on a > > >> CD might be what's needed. > > >> > > >> > > >> Daniel Kunkel wrote: > > >> > > >> > Hi Ian > > >> > > > >> > I'm going to jump in and say I think there may > > be a better way. > > >> > > > >> >>From what I'm reading, I get the idea that you > > want to create some > > >> sort > > >> > of fork in the development in order to have a > > version that is simpler > > >> > and more easily implemented out of the box. > > >> > > > >> > I REALLY don't like the idea of any kind of > > development fork even > > >> though > > >> > I see how alluring it is given the huge > > untapped markets. With a > > >> project > > >> > as big and encompassing as OFBiz, it's easy to > > see how certain design > > >> > decisions have affected the appropriateness of > > the application for > > >> > particular markets. > > >> > > > >> > I would like to see if we can build on the > > strength of OFBiz's > > >> framework > > >> > and create more "interchangeable plug-ins" like > > those in the > > >> specialized > > >> > directory that add or remove features as > > needed. I think this could be > > >> > used to create an app that is easily > > configured for the needs of any > > >> > particular company. > > >> > > > >> > Furthermore, it might help to create a simpler, > > more intuitive > > >> > interface. If the interface is clear and easy > > to use, even small > > >> > companies will appreciate most of the extra > > features. > > >> > > > >> > Perhaps some developers on this list already > > have modules they've > > >> > created can share them as a specialized > > modules. > > >> > > > >> > Thanks > > >> > > > >> > Daniel > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > On Wed, 2007-01-03 at 18:22 +0000, Ian McNulty > > wrote: > > >> > > > >> >>Andrew, > > >> >> > > >> >>Me again :) > > >> >> > > >> >>Right on the money old son. OFBiz light was one > > of the possible > > >> >>strategies that came to mind. > > >> >> > > >> >>The principal would be that to move from a > > high-end, high-value, > > >> >>tailor-made service where a skilled wheelwright > > is needed to > > >> re-factor, > > >> >>if not reinvent, the wheel on every > > installation, to more of a > > >> >>mass-market solution with a wider user-base, > > requires offering easily > > >> >>understood, preconfigured solutions in price > > bands customers can > > >> afford. > > >> >> > > >> >>That's a whole science in itself! > > >> >> > > >> >>In the absence of that, the strategy would be > > to use the net for > > >> what it > > >> >>has proved to be best at. Building user-groups > > and user-generated > > >> content. > > >> >> > > >> >>The functionality of the user interface on ;the > > mailing list we are > > >> >>currently communicating through is proven for > > it's efficacy in > > >> focusing > > >> >>the attention of a relatively small and highly > > motivated group onto > > >> >>resolution of sticky technical issues. But in > > this context, an > > >> avalanche > > >> >>of n00bies asking the same old questions would > > be indifferentiable > > >> from > > >> >>an avalanche of spam. > > >> >> > > > === message truncated === >
