I can’t tell too much just yet but i think it’s safe to say that it’s going to seriously rock the tardis. It will feature an open REST API for your integration pleasures, it will come with a super sweet AIR application that i am sure you will love (not only because it will be 100% open sourced), and the site (handcrafted in Rails and designed by one of the coolest design houses in the universe) is definately going to please your eyes and ears.

Be one of the first to play with it, sign up for the closed beta today!

The problem is that the user needs to install the RPC server before she installs the actual AIR application. The install process should be seamless (one installer installs RPC server, AIR runtime if needed, and the application itself in one go)  and the installer should be as small as possible. Currently there is no info available from Adobe on how to write custom installers that automatically download/install the AIR runtime if needed (is there?).

Artemis is another project aiming at extending AIR using a local socket server, but it seems that the project has been shut down because of the reasons stated above.

So i have been pulling out my hair lately on how to solve that problem.

I think i found a feasible solution. I am not sure because i haven’t tested all this, but i wanted to throw it online for discussion. The drawback is that the user needs to install your application with a OS native custom installer.

First you write standard installers for both Mac OS X and Windows, that install the local socket server either as a service/daemon or as an agent so that the server always starts at system launch or user login. Nothing special here yet.

The trick would be to write a simple SWHX application that basically implements the code included with the AIR Installer badge. That helper application can then be included with the installer, which executes it after the local socket server has been installed.

As i said i haven’t tested this yet (will do soonish), but this should work, no?

The question remains why i don’t just use SWHX for the main app and screw AIR alltogether.

So i finally sat down this weekend and added that.

The code is not tested very well (it works for me but may not work for you) and has no ASDocs yet, so i release it as an alpha version, with the hope of massive bug feedback.. :)

Download: fzip_1_0_52_alpha.zip fzip_1_0_055.zip

New methods in class FZip:

• addFile(name:String, date:Date, content:ByteArray)
• addFileAt(index:uint, name:String, date:Date, content:ByteArray)
• removeFileAt(index:uint)
• serialize(stream:IDataOutput)

Sample code:

// Create file contents
var ba:ByteArray = new ByteArray();
ba.writeUTFBytes("Hello World!");
// Create ZIP archive and add file
var zip:FZip = new FZip();
zip.addFile("hello.txt", null, ba);
// Serialize ZIP into a new file
// (we use the Adobe AIR specific class FileStream here,
// but you can as well use ByteArray or anything that
// implements IDataOutput)
var file:File = File.applicationStorageDirectory;
file = file.resolvePath("hello.zip");
var stream:FileStream = new FileStream();
stream.open(file, FileMode.WRITE);
zip.serialize(stream);
stream.close();

FZip now uses ByteArray.uncompress(CompressionAlgorithm.DEFLATE) instead of the now deprecated ByteArray.inflate(). I also tweaked FZip to throw an exception when a parsing error occurs and no event listener is registered for FZipErrorEvent.PARSE_ERROR events.

AIRRemoteUpdater now gets the local descriptor XML via Shell.shell.applicationDescriptor which was added in AIR Beta 2, and uses the upgraded FZip sources.

Enjoy, and please let me know if you run into any problems with this new release.

Orkut for example introduced footsteps some time ago. A user is able to opt out of this feature (so she doesn’t leave footsteps anymore and can browse other people’s profiles anonymously), but if she opts out she also can’t see other people’s footsteps on her profile anymore. This resulted in many Orkut users creating second dummy accounts that they used to browse anonymously, while footsteps are still enabled on the user’s real account.

Would you see a problem if a social network site has footsteps enabled by default, and the user can opt out (to not leave footsteps anymore) but would still see other people’s footsteps on her profile (as long as those people didn’t opt out)?

What do you think?

[via Tink]

It transparently checks version numbers, downloads the .AIR installer file if needed and triggers the AIR-native update process.

It grabs the version number directly from the remote .AIR file without having to download the entire file, eliminating the potential error prone need of having to put a separate descriptor file online along with the .AIR installer file.

Background:

An .AIR installer file is a PKZIP archive containing metadata files along with the packaged application files. The files contained in a .AIR installer file are, in this order:

1. /mimetype
2. /META-INF/AIR/application.xml (contains version info)
3. /META-INF/AIR/hash
4. /META-INF/signatures.xml
5. packaged application files

The file we are interested in, /META-INF/AIR/application.xml (the “application descriptor file” that contains the version number), is always the second file in the archive. AIR Remote Updater uses FZip to stream in the remote .AIR until (and only until) the application descriptor file has loaded. We can then close the stream, uncompress that file and extract the version number.

More info and download here:
http://codeazur.com.br/lab/airremoteupdater/

• Added support for Adobe Air. The Adobe Air runtime provides a low level inflate method, making it possible to load any ZIP archive and decompress compressed files without the need of injecting Adler32 checksums.
• Added FZipLibrary class for higher level access to files in a ZIP archive. “FZipLibrary processes files (based on file extensions) from an FZip instance and converts them into usable formats. Files can be converted to either a BitmapData or DisplayObject classes. Data embedded in SWF files (like classes) can also be retrieved. Flash’s built-in Loader class is used to convert formats, so the only formats currently supported are ones that Loader supports. As of this writing they are SWF, JPEG, GIF, and PNG.”
• Bug fix: There was a problem with filenames containing special characters. Filename encoding now defaults to UTF-8. In case the filenames are encoded differently in your ZIP, you can specify the encoding in the FZip constructor.

Special thanks to Daniel Wabyick at Adobe for contributing the Adobe Air support!

Enjoy!

http://codeazur.com.br/lab/fzip/

Hello -

This email is regarding a potential security concern related to your
'xxxxxx' FTP account.

We have detected what appears to be the exploit of a number of
accounts belonging to DreamHost customers, and it appears that your
account was one of those affected.

We're still working to determine how this occurred, but it appears
that a 3rd party found a way to obtain the password information
associated with approximately 3,500 separate FTP accounts and has
used that information to append data to the index files of customer
sites using automated scripts (primarily for search engine
optimization purposes).

Our records indicate that only roughly 20% of the accounts accessed -
less than 0.15% of the total accounts that we host - actually had
any changes made to them. Most accounts were untouched.

We ask that you do the following as soon as possible:

1. Immediately change your FTP password, as well as that of any other
accounts that may share the same password. We recommend the use of
passwords containing 8 or more random letters and numbers. You may
change your FTP password from the web panel ("Users" section, "Manage
Users" sub-section).

2. Review your hosted accounts/sites and ensure that nothing has been
uploaded or changed that you did not do yourself. Many of the
unauthorized logins did not result in changes at all (the intruder
logged in, obtained a directory listing and quickly logged back out)
but to be sure you should carefully review the full contents of your
account.

Again, only about 20% of the exploited accounts showed any
modifications, and of those the only known changes have been to site
index documents (ie. 'index.php', 'index.html', etc - though we
recommend looking for other changes as well).

It appears that the same intruder also attempted to gain direct
access to our internal customer information database, but this was
thwarted by protections we have in place to prevent such access.
Similarly, we have seen no indication that the intruder accessed
other customer account services such as email or MySQL databases.

In the last 24 hours we have made numerous significant behind-the-
scenes changes to improve internal security, including the discovery
and patching to prevent a handful of possible exploits.

We will, of course, continue to investigate the source of this
particular security breach and keep customers apprised of what we
find. Once we learn more, we will be sure to post updates as they
become available to our status weblog:

      http://www.dreamhoststatus.com/

Thank you for your patience. If you have any questions or concerns,
please let us know.

- DreamHost Security Team