Thu Apr 25 21:59:53 CEST 2002
> >> Please please please make .ear be a standard (e.g. POSIX) archive
> >> format, usable by standard tools (e.g. tar/cpio/pax).
> >> The world doesn't need Yet Another Pointless Archive Format(TM).
> >> /Mikael
> > Ummm - It's not clear to me the advantages of following a
> >format outweigh the advantages of using a non-standard format....
> > Since I expect an Erlang program to produce the YAPAF file and
> >another Erlang program to consume the YAPAF I don't see why it
> >what the format is. A symmetric pair of term_to_binary and
> >binary_to_term calls is all that is needed - not exactly complex
> If there is any interest, I have not one but two .ear formats with
> encoder/decoders :-) Yes, they are YAPAFs, but straightforward
> bright side, I have archived and installed the entire OTP .beam
> with both. On Solaris and Linux.)
> The main advantage of doing it in Erlang is portability, hence
> (This doesn't argue for a YAPAF, of course, since we could implement
> well-known format in Erlang.) We can use the same code on Windows
> VxWorks as on various Unices. (Using a YAPAF, we also get the
> sword of flexibility :-)
> -- Thomas
As we discussed before Thomas, I think that support for other
resources than .beam files should be supported (i.e. loadable drivers
but make it generic). Support for different architectures in parallell
should be included.
Next had this with its fat binaries.
(It also had utilities to slim the binaries ;-)
BTW, Lack of support for other files is than .beam files is what makes
the network bootloader useless.
Synapse Systems AB
Phone: +46 709 686 685
More information about the erlang-questions