Fernseher - User contributions [en]

MIDI and the organ project

2009-02-24T02:53:42Z

96.42.70.86: /* Chips to use */

MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.

The basics, as I think we will be using them:

Packet basics (we'll only be using 3 byte packet forms):

1 <3: opcode> <4: channel> 0 <7: arg1> 0 <7: arg2>

Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).

opcodes of relevance:
*0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.
*0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.
*0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)

For channels, we will use:
*0x0: Great (Solo) Manual
*0x1: Swell (Accompaniment) Manual
*0x2: Choir (below Great) Manual, if present
*0x3: Solo (above Swell) Manual, if present
*0x4: Echo (above Solo) Manual, if present
*0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.
*0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.
*0x7: Main Pedalboard
*0x8: Great stops only
*0x9: Swell stops only
*0xA: Choir stops only
*0xB: Solo stops only
*0xC: Echo stops only
*0xD: Third Pedalboard stops only
*0xE: Second Pedalboard stops only
*0xF: Main Pedalboard stops only

Our initial organ will only use channels 0x0-0x1, 0x6-0x7.

Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It'd be kinda a lot harder to make work right, I think.

We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi's numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.

Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don't even need to populate the board positions for the other channel boards.

Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don't need a pin for ground or power, I don't think... Though if there is room, I guess we could send it along there, too. Can't hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.

Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.

===Simple algorithm for key change detection===
After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor'ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don't have to analyze it, it hasn't changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.

Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.

Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, "timestamp", first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.

===Chips to use===
*16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)
*1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)
*1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)
*1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)

MailMessage

2009-01-23T06:37:04Z

96.42.70.86: New page: This class represents a Mail Message for the Modjs environment, a straight up MIME message that, when receive processing is performed on it, gets converted from strict MIME RFC-204...

This class represents a Mail Message for the [[Modjs]] environment, a straight up [[MIME]] message that, when receive processing is performed on it, gets converted from strict MIME RFC-2045 compliant encodings and line foldings and whatnot, and when send processing is performed, gets converted to strict MIME RFC-2045 compliant encodings, line foldings, etc. It is mostly a wrapper around [[MimeEntity]], with an additional property to help determine current encoding state, and several methods for encoding/decoding purposes.

To create a new MailMessage:
msg = new MailMessage([[MimeEntity]])
*Creates a mail message with the specified entity in it and converts to RFC-2045 compliant message string.
msg = new MailMessage(textblob)
*Creates a mail message with the specified textblob in it. This gets decoded and parsed into a [[MimeEntity]].

Properties in MailMessages:
*entity: The [[MimeEntity]], decoded and everything, ready to be looked at and analyzed.
*mailable: The textblob, encoded and ready to be mailed out.

Extra methods:
*msg.encode(): Encodes the entity to the mailable property.
*msg.decode(): Decodes the mailable text blob back into the entity
*status = msg.send([path and args string]): Calls msg.encode() and executes '/usr/bin/mail -t' (or the path argument and args) in a ProcessConnection() object, and then sends along the mailable textblob to it, followed by an EOF and then close() and returns the exit status.

HTTPResponse

2009-01-23T06:16:40Z

96.42.70.86:

This class represents HTTP Response messages for the [[Modjs]] environment. It contains information on the status line to be sent back in the response (or that was sent back in the response), as well as the [[MIME]] entity that is the resultant response data and response headers, as a [[MimeEntity]] object. Primarily, this class represents a way for the [[Modjs]] script to return data to the requestor. To this end, there are many obStack related methods. These are only of use if this is _the_ response of the script. Otherwise, they don't really do much. They could, but they don't :) It can also be used to represent that data that is returned when manually requesting information from another HTTP server using a [[TCPConnection]]. In that case, the [[TCPConnection]] needs to be slurped up and passed to the HTTPResponse constructor. For the prime response, the default Content-type: is set to text/html. It can be changed easily though, of course.

To create an HTTPResponse object, the entire response text should be passed to the constructor, like so:
response = new HTTPResponse(response text blob)

Response objects will contain the following properties. They can be queried but usually should not be set directly, instead the obStack, print, setHeader, etc, methods should be used to ensure data consistency.
*statusCode: the status code of the response (such as 401, etc). For prime, this is initially set to 200 (OK) and the contents of this, when the script ends, will get sent back to the client as the status code.
*statusMsg: a brief message used to more easily describe the statusCode. In prime, this is initialized to OK, to go with the 200, but changing this has no real affect.
*prime: an indicator that this is the "prime" response, that is, the one used to respond back to the initial modjs apache request. If this is on, things like sendHeaders(), print() and obstacks are actually important.
*headersSent: an indicator that headers have been sent back for this prime request already. Therefore, new headers that are added, or old ones that get changed, will have no affect.
*obStack[]: stack of text blobs that can be written to, flushed, cleared, aborted, etc., to make handling responses that much easier. Use them! They are great! Also, refer to PHP's obstacks.
*entity: the actual [[MimeEntity]]. Don't manual write to this, please. Reading only!

The methods on the object are:
response.print(string|array of strings)
* prints the string or array of strings to the current obstack blob if there is one. Otherwise, appends it to the entity body and sends it straight out! If headers haven't been sent yet, they would be at that point! beware! Also the status line I guess? Not certain how that works...
response.addMimeData([[MimeEntity]]|array of [[MimeEntity]]s)
* adds the given mime entities to the entity tree, as though printed (meaning, through obstacks). Content-type is not automatically changed, you have to do that beforehand! Including boundary generation (though that can be automatic, when setting to multipart content-type).
response.sendFile([[File API|File]]|array of [[File API|File]]s)
* adds the contents of the given files to the body, as though printed (through obstacks, etc). Note adding a File as an attachment would need to be done through a [[MimeEntity]] containing the file, etc.
response.setHeader(name, value)
response.setHeader([[MimeHeader]])
response.setHeader(name, [[MimeHeader|MimeValue]])
* sets the given header in the top level mime entity to the given value. This is as smart as it can be. Hopefully you haven't sent headers yet! This will change the first header of the given name to the new value, or add a new header by that name. If one already exists and you don't want to overwrite it, you will need to set it in the entity itself. This is quasi-safe... but don't do anything else in there!
response.setCookie(name, value[, expiration [,domain, etc.]])
* sets the given cookie to the new value. If its a new cookie, you will need to specify the expiration and whatnot. This will generate a Set-Cookie: header in the response. Hopefully you haven't sent headers yet. If this is the prime response, this will also add the cookie/change the cookie of this name in the prime request. (maybe?)
response.sendHeaders()
* sends the current set of headers (and the status line, maybe?) out over the wire, if this is the prime response. Sets headersSent. This will mean that subsequent changes to the prime response top level entity will not ever be sent out.
response.obBegin()
* adds a new text blob to the obstack
response.obClear()
* clears the top text blob on the obstack, but leaves it there
response.obFlush()
* takes all the text of the top blob on the obstack and prints it to the lower one, or straight out. Leaves the top blob (now empty) on the stack.
response.obFinish()
* performs an obFlush() but also removes the top blob on the obstack
response.obAbort()
* performs an obClear() but also removes the top blob on the obstack

Server API

2009-01-23T06:14:50Z

96.42.70.86:

The server object is a global object representing the server interfaces for logging and environment and such in my [[Modjs]] implementation.

Data members on the global server object:
*env: array of environment variables, including standard request headers and server information

Functions on the global server object. Low-level Apache/spidermonkey interface methods. Please use appropriate File and HTTPResponse methods wherever possible.
*logNotice(string|array of strings): function to log a notice (or a list of notices) to the server error log
*logError(string|array of strings): function to log an error (or a list of errors) to the server error log
*status = runCmd(path, array of args): executes the given command on the server (with the httpd daemon's permissions!). Script execution will block until finished, and will return the exit status. arguments will be escaped or quoted as necessary
*sendHeaders(): Push the headers to the client
*sendString(string|array of strings): Print the strings specified to the client.
*sendFile(path): Print the strings specified to the client.
*setOutgoingHeader(key, value): sets the first outgoing header of the given keyname to value, and removes any extra headers of that name. If key is content-type, content-encoding, or content-language, also sets the appropriate entry in the request_rec.
*addOutgoingHeader(key, value): adds the outgoing header of the given keyname to value. If key is content-type, content-encoding, or content-language, also sets the appropriate entry in the request_rec.
*string = base64encode(string): encodes the string in base64
*string = base64decode(string): decodes the string from base64
*include(path): Runs the script specified by path in the current context

HTTPRequest

2009-01-23T05:35:49Z

96.42.70.86:

The HTTPRequest class represents an HTTP Request message for my [[Modjs]] environment. It contains a request line and other information about the requestor, and a [[MIME]] entity ([[MimeEntity]]) for the request headers and data. Its primary use will be for the script writer to see the request from the browser to the server, and what data they are sending over. It will do a little bit to parse out cookie variables, query variables, and post data variables to make the script writer's life easier. It can also be tied back to a [[HTTPResponse]] object to make inclusion of cookie headers mostly seemless when new cookies are defined and the response is sent back with them.

When a [[Modjs]] script builds a completely new HTTPRequest object in order to send it over a [[TCPConnection]] or the like to a different, remote, server, it will behave a little bit differently, in that, rather than parsing the headers and request data in order to get cookies/queries/posts, it will have the ability to unparse those variables sets back into headers and request data, as needed (and only if requested). And not cookies. Just too much work for too little benefit.

To create a new HTTPRequest object, the constructor is called:
request = new HTTPRequest(host [,method [,path [,query [,version]]]])

Note that except for host, the rest of the arguments could be passed as one string. They are essentially joined and reparsed to verify that the correct syntax is used for the request line. host sets the required Host: header in the mimeentity on creation. If the method is POST, the Content-type: header also gets set to the default value of application/form-data.

This could throw an exception if method or query string are malformed:
HTTPRequestException

The object will have these properties:
*method: the request method
*path: the request path
*query: the request query
*host: the request host
*protocol: the request protocol version
*client: the requesting client ip
*prime: indicates whether this is the "prime" request, that is, the one that started the script up and needs to be quasi-special.
*entity: the [[MimeEntity]] for the data in this request, including headers.
*queryVars: the query is parsed and proper variables are put in here as name/value pairs. Last one sticks. If you reuse a name, you'll have to go to the real query to get both values. On outgoing requests, this will get slurped up and urlencoded and _added_ to the query property as part of the query string in the request line. Be aware!
*cookieVars: the Cookie and Cookie2 headers are parsed and proper variables are put in here as name/value pairs. If there are duplicate names, the last one sticks. Go to the actual headers if you need more, or property values. Note that this is not a magic cookie jar. For the outgoing response, if you need to add new cookies, you must add the cookie using the [[HTTPResponse]] addCookie() method. For outgoing requests, the cookie variables placed in here do not get magically merged into the appropriate Cookie: header, since it doesn't have enough information.
*postVars: If the method is POST and the [[MIME]] entity is correct, posted variables get parsed and put in here as name/value pairs. If there are dups, again, the last one sticks. You may have to actually decode the entity if you need more details. On outgoing requests, this will get slurped up and put as variables in the POST data, in the appropriate section, depending on current content-type and method, etc.

The object has a couple methods, toString() which essentially converts to a single string, appropriate for sending over a TCPConnection. This will do queryVars and postVars recombination, if there are any variables there. Be aware! It will also use proper CRLF EOLs for headers (I think?). Also, getRequestString() which combines the request information and returns the request line in the current state based on properties and query variables.
string = request.toString()
string = request.getRequestString()

HTTPRequest

2009-01-23T05:29:28Z

96.42.70.86:

The HTTPRequest class represents an HTTP Request message for my [[Modjs]] environment. It contains a request line and other information about the requestor, and a [[MIME]] entity ([[MimeEntity]]) for the request headers and data. Its primary use will be for the script writer to see the request from the browser to the server, and what data they are sending over. It will do a little bit to parse out cookie variables, query variables, and post data variables to make the script writer's life easier. It can also be tied back to a [[HTTPResponse]] object to make inclusion of cookie headers mostly seemless when new cookies are defined and the response is sent back with them.

When a [[Modjs]] script builds a completely new HTTPRequest object in order to send it over a [[TCPConnection]] or the like to a different, remote, server, it will behave a little bit differently, in that, rather than parsing the headers and request data in order to get cookies/queries/posts, it will have the ability to unparse those variables sets back into headers and request data, as needed (and only if requested). And not cookies. Just too much work for too little benefit.

To create a new HTTPRequest object, the constructor is called:
request = new HTTPRequest(host [,method [,path [,query [,version]]]])

Note that except for host, the rest of the arguments could be passed as one string. They are essentially joined and reparsed to verify that the correct syntax is used for the request line. host sets the required Host: header in the mimeentity on creation. If the method is POST, the Content-type: header also gets set to the default value of application/form-data.

This could throw an exception if method or query string are malformed:
HTTPRequestException

The object will have these properties:
*method: the request method
*path: the request path
*query: the request query
*host: the request host
*version: the request version
*client: the requesting client ip
*prime: indicates whether this is the "prime" request, that is, the one that started the script up and needs to be quasi-special.
*entity: the [[MimeEntity]] for the data in this request, including headers.
*queryVars: the query is parsed and proper variables are put in here as name/value pairs. Last one sticks. If you reuse a name, you'll have to go to the real query to get both values. On outgoing requests, this will get slurped up and urlencoded and _added_ to the query property as part of the query string in the request line. Be aware!
*cookieVars: the Cookie and Cookie2 headers are parsed and proper variables are put in here as name/value pairs. If there are duplicate names, the last one sticks. Go to the actual headers if you need more, or property values. Note that this is not a magic cookie jar. For the outgoing response, if you need to add new cookies, you must add the cookie using the [[HTTPResponse]] addCookie() method. For outgoing requests, the cookie variables placed in here do not get magically merged into the appropriate Cookie: header, since it doesn't have enough information.
*postVars: If the method is POST and the [[MIME]] entity is correct, posted variables get parsed and put in here as name/value pairs. If there are dups, again, the last one sticks. You may have to actually decode the entity if you need more details. On outgoing requests, this will get slurped up and put as variables in the POST data, in the appropriate section, depending on current content-type and method, etc.

The object has a couple methods, toString() which essentially converts to a single string, appropriate for sending over a TCPConnection. This will do queryVars and postVars recombination, if there are any variables there. Be aware! It will also use proper CRLF EOLs for headers (I think?). Also, getRequestString() which combines the request information and returns the request line in the current state based on properties and query variables.
string = request.toString()
string = request.getRequestString()

Global object extensions

2009-01-23T05:27:33Z

96.42.70.86:

A couple functions, I didn't know where to put, but definitely wanted for my [[Modjs]] implementation, so they went onto the global object. If I can think of a better place for them, they may move. This page can also list all the classes I've added and that are available and whatnot.

Used to convert an object to a JSON compliant string and back again:
string = jsonEncode(object)
object = jsonDecode(string)

These could throw exceptions if the object or string cannot be converted or is otherwise malformed:
JsonCodingException

The global objects I've added are these:
*[[server API|server]]: Controls the environment, logging, and general low-level write back to the server, etc.
*[[HTTPRequest|request]]: The incoming HTTP Request from apache through [[Modjs]]. This is the prime [[HTTPRequest]].
*[[HTTPResponse|response]]: The outgoing HTTP Response from this script back to the client through apache and [[Modjs]]. This is the prime [[HTTPResponse]].

Constructors on the global object now:
*[[File API|File]]
*[[HTTPRequest]]
*[[HTTPResponse]]
*[[MailMesage]]
*[[MimeEntity]]
*[[MimeHeader]]
*[[MimeHeader|MimeValue]]
*[[MimeHeader|MimeProperty]]
*[[ProcessConnection]]
*[[TCPConnection]]
*[[DbConnection]]
*[[DbConnection|DbStatement]]

Global object extensions

2009-01-23T05:26:40Z

96.42.70.86:

A couple functions, I didn't know where to put, but definitely wanted for my [[Modjs]] implementation, so they went onto the global object. If I can think of a better place for them, they may move. This page can also list all the classes I've added and that are available and whatnot.

Used to convert an object to a JSON compliant string and back again:
string = jsonEncode(object)
object = jsonDecode(string)

These could throw exceptions if the object or string cannot be converted or is otherwise malformed:
JsonCodingException

The global objects I've added are these:
*[[server API|server]]: Controls the environment, logging, and general low-level write back to the server, etc.
*[[HTTPRequest|request]]: The incoming HTTP Request from apache through [[Modjs]]. This is the prime [[HTTPRequest]].
*[[HTTPResponse|response]]: The outgoing HTTP Response from this script back to the client through apache and [[Modjs]]. This is the prime [[HTTPResponse]].

Constructors on the global object now:
*[[File|File API]]
*[[HTTPRequest]]
*[[HTTPResponse]]
*[[MailMesage]]
*[[MimeEntity]]
*[[MimeHeader]]
*[[MimeValue]]
*[[MimeProperty]]
*[[ProcessConnection]]
*[[TCPConnection]]
*[[DbConnection]]
*[[DbStatement]]

MimeHeader

2009-01-23T05:12:35Z

96.42.70.86:

A MimeHeader object represents a single header in a MIME or HTTP message in a easier to use format for [[Modjs]] scripts. Each header can have an array of MimeValue objects, which can have an array of MimeProperties. The true format of these are described in [[MIME]].

To paraphrase, a true MIME header is a name:value[,value...] pair of form:
header := header-name ':' header-value CRLF
header-value := values
values := (value-exp ',')* value-exp

Each value is of form:
value-exp := real-value (';' property-exp)*
real-value := value-key ['=' value-value]

And each property then is of form:
property-exp := property-key ['=' property-value]

A new MimeHeader can be created using:
header = new MimeHeader(name, array of MimeValue objects)
header = new MimeHeader(name, raw value string)

If the header cannot be created (if the objects passed in aren't duckable to MimeValue, or the string isn't valid header value formatted), an exception can be thrown:
MimeHeaderException

A new MimeValue can be created using:
value = new MimeValue(raw value, array of MimeParameters)
value = new MimeValue(value name, value content, array of MimeParameters)
value = new MimeValue(raw value string)

These could throw:
MimeValueException

A new MimeProperty can be created using:
property = new MimeProperty(property name, property value)

Once a header is created, it has these properties:
*name: The header name
*values: array of MimeValue objects

The header has several methods:
string = header.getName()
array of MimeValues = header.getValueList()
header.addValue(MimeValue)
MimeValue = header.removeValue(index)
MimeValue = header.getValue(index)
string = header.toString()
string = header.getValue(value name)
string = header.getAllValues()

The value has these properties:
*value: The value name, or "true" value
*content: the value content
*properties: array of parameter name/value pairs

And these methods:
string = value.getValueName()
string = value.getValueContent()
string = value.getValue()
value.setValueContent(string)
array of MimeParameters = value.getPropertyList()
value.addParameter(MimeParameter)
MimeParameter = value.removeParameter(index)
MimeParameter = value.getParameter(index)
string = value.toString()
string = value.getParameter(parameter name)

MimeParameters have these properties:
*name: the parameter name
*value: the parameter value

And these methods:
string = parm.getName()
string = parm.getValue()
parm.setValue(string)
string = parm.toString()

MimeEntity

2009-01-23T05:11:06Z

96.42.70.86:

MimeEntity represents a standard [[MIME]]/HTTP entity, including headers and body. For [[Modjs]], there is a MimeEntity in [[MailMessage]]s, [[HTTPRequest]]s, and [[HTTPResponse]]s, including the request that brought about the modjs script invocation, and the response that will be sent back.

MimeEntitys can be created manually with:
entity = new MimeEntity(array of [[MimeHeader]]s, body)

If this doesn't work for some reason, it could throw
MimeEntityException

Each MimeEntity has the following properties, which may be queried, but really shouldn't be edited directly.
*headers: the array of [[MimeHeader]]s for this entity
*body: the raw body of this entity
*type: the major content type of this entity
*subtype: the subtype of this entity
*id: the content-id of this entity, if it has one
*boundary: the boundary string of this entity
*children: an array of MimeEntities representing the children of this entity, in the multipart and message types
*leader: In a multipart or message entity, the part of the body before the first boundary
*trailer: In a multipart or message entity, the part of the body after the last boundary

The entity also has the following methods, which should be the primary method of modifying the entity if needed.
string = entity.toString()
string = entity.getContentType()
string = entity.getBoundaryString(last?)
entity.addHeader([[MimeHeader]] | array of [[MimeHeader]]s)
*adds the given headers, even if they already exist
array of [[MimeHeader]]s = entity.getHeader(name)
*gets all headers of the given name
string = entity.getHeaderValue(name)
*gets the value string (raw) of the first header with the given name
entity.setHeader(name, value)
*changes the raw value string of the first header with the given name
entity.clearBody()
entity.setBody(string)
entity.addToBody(string)
entity.addMessageEntity(MimeEntity)
entity.addMultipartEntity(MimeEntity | array of MimeEntitys)
MimeEntity = entity.removeChildEntity(index)
MimeEntity = entity.getChildEntity(index)
MimeEntity = entity.getChildEntityById(id)