ebollens / dts Goto Github PK

Right now, the server and client files are all coupled under a single directory. To emphasize the ability to decouple these to the point of federation, or even minimally to the point of running one copy of DTS on a server hosting multiple apps that use it, they should be decoupled.

The current minifier jsmin.php has two problems:

1. It is a dead project
2. It does not do local variable obfuscation

While the former isn't an issue so long as no bugs are encountered, the latter is a problem because the payloads are larger than they need to be. Using YUI (an online example at http://www.refresh-sf.com/yui), compression cuts down another 24% on file size.

Updates today are missing in-line documentation in some places, so this needs to be added.

MWF 1.3 made some changes to DTS.

This library need to be brought inline.

Client-side PHP code right now can use DTS_Cookie to access the cookies written by DTS. However, these do not have "friendly" names, nor are their contents friendly, instead chosen for smaller payloads. As such, need client-side PHP libraries to interpret these in a more coder-friendly manner.

MWF just used classifications to break up files into multiple grades. However, DTS should expose all capability information derived from dts.capability. Because of the large number of these, need to come up with a scheme for encoding them as tightly as possible - likely hex encoding four boolean values to one byte. These will then be interpreted by a client-side library designed for this purpose as described in #3.

Right now, the user agent cookie is way too big, and I'd like to see if I can tighten it up. This is less-so true with the classification cookie, but still it's got a few extra bytes I could milk out by getting rid of the urlencoding. However, this is tricky, since urlencoding is required for cookies, meaning need to come up with a scheme that doesn't require encoding special chars.

Should provide a build script that can prompt a user to configure their js.php and passthru.php files and render it out as static .js files so that PHP isn't needed to run this - of course, federation.php will still need to be run, or a ported equivalent in another language, but the simplicity of this latter file is more conducive than the others.

There are some other screen attribute we might be able to query.

Here's a good article on the topic:
http://tripleodeon.com/2011/12/first-understand-your-screen