Re^2: Perl::Minimal -- the good, bad, and the ugly...

[taint]

Thanks for the reply, wjw.

It's this sort of reply that IMHO, helps define "minimal Perl". In my conception, it would simply be the smallest amount possible to bootstrap itself. But with the addition of just enough to bootstrap NETwork. Which doesn't necessarily even include the CPAN. Because, where the CPAN is concerned. If you have a working network, you can get the CPAN related stuff. If you feel that/those are necessary. You might have something else that suits your needs, where this sort of thing is concerned.

I've been interested in the embedded arena for several years now. I see PHP in use quite a bit [more] than Perl. It's used for things as high-level, as providing a web interface to configure your network -- think Gateways, Routers, and IP/Network filters. To lower-level tasks, such as rc/init. To writing out the disk images, and querying user for setup/installation decisions. Personally; I can easily see, where Perl would clearly be the superior choice for this sort of use-case. Not only does it provide for all the applications just mentioned. But it (where WEB based needs are concerned) can actually provide a web server. Which PHP can not.

I have a "boat load" of devices -- Routers, Switches, Gateways, and CPE's (Customer Premise Equipment -- frequently called modems). That I intend to re-write, or modify the OS (Operating System) on. I intend to use FreeBSD, but any Linux, or other, could also be chosen, by anyone interested in such things.

As I stage for all of this. I needed to address the "scripting" of much of this, and the long-term (resident) applications/scripting methods best suited. I decided (for many of the reasons already mentioned above) that Perl would be the perfect/best choice. Save one thing; SIZE.

So for this use-case; I only want what is absolutely necessary for Perl to bootstrap itself, and just enough for Perl to utilize the (inter)NET. From there, I can manage any other needs/additions, that may be required to meet the overall needs of such an application.

This is only one possible use-case. I can easily imagine a myriad of other use-cases, that would benefit from a "Bare Bones" version of Perl. That can be expanded, as needed.

Other thoughts?

Thanks again, wjw, for taking the time to respond.

--Chris

[wjw]

One of the items I would be particularly interested in is an OPC module for PLC's. Almost all factory floor automation is run on PLC's, the development environments for which are written by MS Platinum Partners, and generally is buggy, slow, and costly to keep updated(licensing is outrageous from my perspective). Some of the big names are GE and Rockwell, though there are many more.

I attended an conference/trade show in Chicago last year where a company had developed a 'card' which natively talked to both the PLC and an MSSQL DB, acting as a direct link between the manufacturing equipment/cell and the database. This is unique in that under normal circumstances, data is collected by the PLC and sent via some communication channel(there are many) to an OPC server which then stores the data, and may push that data on to a DB or a DB may 'query' the OPC service where the data is stored. This middle-ware adds latency and bandwidth overhead where it is not needed.

Generally, PLC are for, and very good at, machine control. They are really not designed for applying/supplying business logic. Just machine control. Never-the-less, data from machine control is often good for and used for much more than just making sure the given machine operates properly and safely. It is in fact useful for Data Driven Decision making at the business level.

With that short description out of the way: Those 'cards' that plug into a PLC are just embedded systems that bypass the middle-ware, thus reducing the latency issues, and much of the bandwidth as well. There is no reason those embedded system need to be running proprietary software. And Perl would bring an enormous amount of flexibility(not to mention cost reduction) to the table in this regard.

This is just one more example of the potential usefulness of your concept of minimal Core Perl's. OPC is actually and open standard which means Perl modules could be developed for this purpose. Being able to break away from the M$ paradigm on the mfg. floor would be, in my view, very attractive.

There have been some other folks here at PM that have used OPC and Perl...( Like here)

[taint]

Indeed, wjw.

I had envisioned many possibilities, over the years. But yours is one that never occurred to me. In spite of the fact I have spent several years working with CNC -- both for metal, and for wood manufacturing. While, in those cases, the cards merely contain routines, which can be re-written, or changed at any time. The one you're introducing seems quite interesting, and seemingly, far more complex. And indeed, could be an ideal application for a Minimal Perl. ++ for bringing it up. :)

I'm all in for this (Minimal Perl), and am more than willing to make the commitment. There's just too many reasons/applications, to overlook it's usefulness.

At this point, for me. It comes down to the "mechanics" of it all. Both to providing Public Resources, and, more importantly, figuring out the best way to accomplish the "actual creation". As to "public resources"; some sort of RCS, VCS will/should be created. But with the myriad of possibilities available. Exactly which will perhaps require some time, and feedback to best determine -- a consensus, from anyone wishing to be involved. I have the resources, to provide for any one of them. I'd also be interested in suggestions, and or pointers, for the best approach to actually create this "Minimal Perl". There seems to be so many possible directions to take. I'd really feel more comfortable hearing from others, before investing much time in a direction, that was not the best choice. :)

Thanks for pointing out another great potential use for Minimal Perl, wjw.

--Chris