> >The knowledge gathered from writing the modules Storable, > >Freeze::Thaw, and Data::Dumper, should be studied very carefully. Those are my lifeblood, that's why I proposed having them in the core as being key to persistance and communication. I store in binary and communicate with Data::Dumper in default mode. The new feature in emitting as described to me, is the possiblity of emitting the XS'd code, allowing perl aware browsers to run every bit of CPAN. > >Of course also the other bytecodes like JVM, Emacs Elisp, and so on, > >should be researched. When all the dust settles, there should be enough left over for a new language, sort of like the original crucifix. There are enough splinters to build a train trestle. > I'd rather not have to have code to deal with all > of them in everyone's perl. (Of course, I'm not sure what the alternative > is...) Multiple formats ?? Using linux's "common denominator priciple" the majority of boxes will be x86 cpu'd. It seems most likely that they will be emitting into the cache or to boxes of their own species. On the part of servers, they would be robust enough to have multiple copies of the byte code ( and cross compiled XS'd modules ) to satisfy all of their receivers, you know, clients ;) This particular argument supports the native platform in the core w/ cross platform modules and less efficient platform neutral module for whomever gets left out. Finally, new buzz words: emitter/receiver
