>I could understand fromText and fromBinary if they were class methods that returned a newly allocated 
>and constructed message initialized with the specified data (essentially a class factory). That would be in 
>keeping with other APIs.

That's the idea and that is also how it is currently implemented. fromText is not a class method but a
module function that returns a new Message class instance.

>fromText currently just creates another literalData object and adds it to the packet list which is definitely 
>not the right thing.

No, see above.

>getLiteralData is currently pretty useless, it just returns literalData's internal state without any context to tell 
>you what it is, it would make more sense to have it return the literalData object, which would make 
>getText and getBinary redundant.

The context you won't get from the message anyway. GPG for example creates by default all literal data
packets as 'binary'. So you need to guess that it contains text and maybe utf8.

>If you still want getLiteralData then have it return the object rather than the internal data buffer.

I'm not completely opposed to having a getLiteralDataPacket method, I just try to avoid returning packets
in the Key and Message class layer if possible. If you need to go to the packet layer you can always do
a:
```
your_msg.packets.filterByTag(enums.packet.literal)
```
So let's move on for now. The API is in an evolving state, we can come back to this topic e.g. when
adding PGP/MIME support and really have to deal with binary data.

I will merge this PR and implement the EOL normalization as discussed.