- * open - just about as open as any format can be!
- * searchable - yes, very. especially with Microdata or RDFa tags to describe data content
- * portable - yes, very. virtually all modern operating systems support at least one decent web browser and there are countless other HTML/XML tools out there
- * compressible - yes, depending. Depending on how much "compression" really means to you - assuming you're simply storing the actual text content and not images of text then HTML is obviously superior to all other formats. If you need graphics and diagrams (not photos), you can use embedded SVG to store near-perfect resolution images and shapes. and embedded uri's to hold the photos/images right there in the document with "data:image/png;base64,...".
- * editable - yes, surprised? It may not always be pretty or easy, but you can use MS, Open, or Libre offices to load/edit/save HTML documents. Don't let your head explode... I know HTML documents generated by these editors are ugly as sin - but you can always edit the tags yourself (which I personally prefer) if you don't want to fight with a fickle GUI.. you can't really do anything like that in a
I'm just not sure why it's a question.. it's the format . . for
Project: Evolutionary Assembly Language (EAL aka poxEAL)
Again, the project specifications are still in the design phase, so there is no software to download yet - just lots of specs working out the conceptual blueprint first. No point in coding something obviously flawed... and I know there are conceptual holes to be filled. There's no magic or supernatural claims involved, just statistics and probability... thousands of monkeys at typewriters banging out software, not Shakespeare.
Summary: EAL is a multi-purpose programming language and environment designed to solve problems using guided auto-generation of program modules. EAL adopts various concepts from the languages LISP, Basic, and generic assembly - but is NOT meant to be a manually-coded language for end-users. Provided with a batch of properly formatted "task scenarios", EAL uses a error-friendly syntax to attempt self-generated (semi-random or mutated) solutions to those tasks. Code modules are evaluated for their various fitness "grades" (size, cycles, errors, correctness, extraneous output, etc.) and the most useful modules stored and catalogued for later reuse and mutation. While you sleep, an EAL environment could be left running to optimize existing code on it's own. You can still write your own EAL program by hand.. but the breakthrough will be when you don't have to.
Much more info is in the docs, and please provide any feedback with the "comments/subscribe" form in the docs.. I desperately need written peer review
I believe it just isn't possible to fix the spam problem in email as it currently exists. All is not lost, because auxiliary communications (phonecalls, texting, Twitter, Dropbox, Facebook, Skype, etc) are better suited for specific types of communication and are self-partitioning. Email is often just as boring and disappointing as physical mail - mostly advertising junk. Because it is based on physical mail, we can't really complain - it's doing exactly what we designed it to do.
Fundamentally, the problem with the current SMTP infrastructure is that it is based on Recipient-liability without any real Sender-liability. It is the recipient's responsibility to have some gargantuan "put junk here" box instead of a reasonably-small tray for other's to say: "I have something for you, encrypted with this secret key, find it on my server here __
That would handle the storage penalty (the message is waiting in their outbox or application, sent to your inbox only when you choose to accept it). If the message is SO important, and you're REALLY who you say you are, then I can get back to you when I want to read/download your message - making the sender easier to authenticate. And both parties would know when the message has been received, or if the message has been read before the intended recipient chose to accept it.