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

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)

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw

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

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Aside from my previous reply to this. While examining the possible avenues toward actually building "Perl::Minimal". I happened upon [albeit dated] some related ports of Perl. As in small(ish):

• TiVo Series 2
• Perl for WinCE devices
• and
• Sharp Embedix for Sharp Zaurus SL-5500

I intend to examine these more closely, as they may be good reference points. I also thought it worth listing here, for future interests, here on PM. :)

--Chris

I actually have two Zaurus SL-5500's at home. And Perl is on one of them as I recall. Will have to check it out when I get back there to see what it looks like. Been years since I have used them... . If you run into questions you can't find answers to on the web regarding that Perl, let me know. Will see if I can find them for you on the device itself. Not sure what that might be, however t'is a resource if you find the need...

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw