Monthly Archives: October 2003

Ted, Why suggest Flash Player / IDE features now?


Yes, I realize that MX2004 just shipped (and soon again) but I would argue that now is the perfect time to suggest new features.

I try to think in terms of Macromedia’s product development cycle. You see when we are learning the new beast, they have moved onto development of the next one. Like all software projects they start with high level planning and a broad requirements discussion. What is truly amazing about Macromedia is that our opinion really does shape product development directly. I never realized this until I experienced it first hand.

Just after the release of Flash MX, it was January 2002. I was complaining on Flashcoders, to “Fork the IDE” in that the Flash product was serving too many masters (designer, animator, developer) yet didn’t fully satisfy any one market completely. I then received an email from Peter Goldie (Macromedia) and was asked to have a conversation about Flash and PowerSDK. Peter wanted to know exactly what I wanted in the product and how it would better suit my needs and the needs of my clients. At the time, I wanted a specialized IDE for component development (truth be told, I still do). I complained that the development paradigm was not ideal for developing applications with components and that for some the timeline paradigm wasn’t a good fit. The discussion also leaned toward accommodating Delphi and VB users with a consistent event/component model. The discussion ended and lots of time passed…..

18 months later…..MX2004 & MX2004 Professional Released

The first thing that caught my eye was that Flash was now 2 distinct products. One was specialized for the development of applications and that version supported a paradigm that didn’t have a timeline, Form based development. The component model had been overhauled and the event model used single words lacking the preceding “on”. I then recalled my conversation with Peter, wow they really listened!

Now please don’t hate me all at once, I was not directly involved in the addition of these features, the heavy lifting was done by much more talented individuals. I cannot imagine delivering 2 development paradigms in a single product. Actually I would wager that Royale adds yet another paradigm to the Flash Professional IDE. ;)

What is very important here is that:

1. Macromedia listens intently to their customers.

2. Macromedia acts based on our opinion of what a product should do.

3. Now is the perfect time to affect change within the Flash product line.

If you have a feature itch, send it to Macromedia, post it to Flashcoders (OT) or Blog about it. You might be pleasantly surprised when you open MX 2006.

Here is my request.

Cheers,

Ted ;)

Flash Player Feature Request – Continuation Support (Practical Threading)


Continuations are a simple threading model that is supported in several stack based systems. So what exactly are continuations? And how should Flash support them?

Continuations are special functions that never return to the stack and allow the stack to continue processing. The execution of a continuation is thus parallel to the operation of the stack. Continuations run until they complete. Most often they execute another continuation or call themselves recursively. When execution reaches the end of a continuation, the execution ends and all resources are returned / garbage collected.

In most stack based systems (Flash, Python, Java), when you call a function, stack processing moves to processing the function and returns to the next instruction after the function is executed. This forces the stack to always work under a single thread and never allows the system to process ‘N’ items in parallel.

Example of continuation support for ActionScript:

myContinuation = continuation(){

trace(‘myContinuation Executing’)

//if data is true call the continuation again

if (mydata ==1){ arguments.callee() }

//if this point is reached kill the continuation

}

mydata = 1

myContinuation()

trace(‘hello’)

mydata = 0

trace(‘end’)

Output:

myContinuation Executing

hello

myContinuation Executing

end

Output without continuation support:

myContinuation Executing

256 levels of recursion were exceeded in one action list.

This is probably an infinite loop.

Further execution of actions has been disabled in this movie.

This would add a simple light parallel execution model to the Flash Player providing a solution to a entire host of problems:

1. Parallel instantiation – Shorten the delay in instantiating components, frameworks, etc.

2. Parallel execution of event listeners – All events would be processed at close to the same time frame, vs. sequentially.

3. Parallel events execution – Allowing player events to be processed at once independently.

4. Process XML in parallel

5. {Your reason here}

A system independent threading model is just what the Flash Player needs to escape the performance related problems of the current architecture. Even with the enhancements in v7 of the player, the V2 component model takes the player to the performance limit. This is a direct result of Flash being a stack based system without support for parallel processing.

To support this initiative please do the following:

1. Sign the comments showing your approval for Macromedia to develop this feature

2. Send this request in parallel to Macromedia Wish Form

Comments and suggestions are always welcome.

Thanks,

Ted Patrick

PowerSDK Software Corp.

Help … PowerSDK Chat Client API


I need your help. We are building a specialized chat server for Flash and wanted to release the Alpha API for public comment. An alpha version of the server will be released next week allowing you to run the server locally and build applications. Any feedback you can provide would be most helpful to me. Please forward comments to ted@powersdk.com.

Thanks,

Ted :)

PSDK:Chat Client API – Alpha Review

————————————————————-

// make a server object

myChat = new com.psdk.server.chat()

// connect to a server:port

myChat.connect (‘server’, 7000)

//login to the server with a username

myChat.login(‘ted’)

There are 2 primary objects, users and rooms. Once you login, these objects appear, populate automatically, and allow you to send and receive messages. Here are a few ways to use the users and rooms objects:

// send a message to ‘Fred’

myChat.users.fred.send(‘Yo what is up!’)

// execute a method on freds client

myChat.users.fred.explode(‘abc’,123)

// get info on fred

myChat.users.fred.info()

//Loop through users and send a message to all

for (var a in myChat.users){

myChat.users[a].send(‘Weeeeeee…’)

}

// enter a room – if the room doesn’t exist, it will be created automagically

myChat.rooms.hotel.enter()

// send a message to the room

myChat.rooms.hotel.send(‘This room is great!’)

// execute a room method – This goes to all users in the room and executes on the room object

myChat.rooms.hotel.explode(‘KaBoom!’)

// get info on hotel

myChat.rooms.hotel.info()

// exit a room – if you are the last one in the room, it is destroyed automagically

myChat.rooms.hotel.enter()

//Loop through rooms

for (var a in myChat.rooms){

trace(a)

}

When you receive a message, events are fired in several locations depending on the object in question.

1. Add an event to a class

//class for user objects

com.psdk.server.chat.user.prototype.onlogoff = function(){}

//class for room objects

com.psdk.server.chat.room.prototype.onrecieve = function(message){}

2. Add an event to the Chat instance – All events are recieved here

myChat.onlogin = function(){}

3. Add an event to a User or a Room instance

myChat.users.ted.onrecieve = function(message){}

myChat.users.ted.onrecieve = function(message){}

4. Subscribe to events via a listener

myChat.addListener(‘onclose’, this)

Chat instance – onconnect, onclose, onlogin, onlogoff, onenter, onexit, oninfo, onexecute, onrecieve, onerror

Room instance – onenter, onexit, oninfo, onexecute, onrecieve, onerror

User instance – onlogin, onlogoff, onenter, onexit, oninfo, onexecute, onrecieve, onerror

Listeners – onconnect, onclose, onlogin, onenter, onexit, oninfo, onexecute, onrecieve, onerror

The current build of the library adds 2.4Kb to your swf for full functionality. The library will also ship in .as and swf formats to allow runtime importing and use of the server. The client will be open source using a BSD license

About the server:

The server uses a special optimized core that allows us to support many types of socket based protocols including, HTTP, HTTPS, Remoting, RTMP, XMLSockets in a scalable cross platform manner. The core was built independent of the individual servers and allows us to create servers on demand. The individual servers are simply events that render a protocol back to a client via a socket. It is very simple design that allows us to build sophisticated servers in a fraction of the time.

The server will be supported on the following platforms: OSX, Win32, Linux, FreeBSD, BSD. In intial testing, the core was able to support an abusive quantity of connections as follows: Windows:2200 connections, FreeBSD:8000 connections, OSX:6000 connections, Linux:untested. An advanced model of the server will support clustering across many servers.

On the chat server, the protocol is plain text (not xml) thus the messages are very small as methods are single characters space delimited with null byte termination. The chat server does not store any data on the local file system and all processing is in memory making user and room processing very fast.

The price point for the chat server is very low compared to the current market as we will be providing customization services allowing us to tailor the server protocol and client library to a specific application. The default chat server will sell for below $150 and there are no connection / user restrictions. Clustering support will be additional in a later version. Development servers will be free and are restricted to running on the localhost.

Again, any thoughts on the Client API would be most helpful and depending on the feedback might be worth of a free license.

Thanks,

Theodore Patrick – Founder

PowerSDK Software Corp.

A Runtime Perspective


The debate over AS1 or AS2 is interesting but in the end its all bytecode. Regardless of what toolset made the swf file, the player will interpret the bytecode instructions(compatible or not). What is important is that the swf meets your requirements for functionality and usability.

Different development approaches have merit but all approaches are not created equally for the problem at hand. Some problems are better solved procedurally, some via objects, some via components, and some via a framework or a pattern. In the end you are trying to solve a problem and the toolset simply provides options towards a particular solution. The argument that there is only one way to solve a problem is ego-driven crap.

Personally, I am very comfortable with AS1 and can solve problems with it easily. Having worked with it for years, I know the ins and outs of shaping solutions with it. When I write a line of code with AS1, I know what will happen at runtime. With AS2, that isn’t the case, yet.

AS2 provides compile time tools to allow you to detect subtle errors in development. The additions of Classes, Interfaces, and Type Safety are very powerful if used properly and very destructive if used improperly. Developing with them effectively requires understanding how they impact software at runtime. Unfortunately there are only a handful of developers that understand the runtime perspective of AS2 (most work for MM), although this will change over time.

If you understand what a language does at runtime, you can use it in many unexpected ways to solve problems. Good developers understand the runtime perspective of a language, great developers shape solutions from this understanding.

“I should think you Jedi have more respect for the difference between knowledge and wisdom.” -Dex

cheers,

ted ;)

Darwin 7 (OSX 10.3) updated on x86 too…


I find it interesting that Apple continues to update the X86 version of OSX. One could say that they are keeping their options open in regard to future chipsets, but selling a first class hardware compatible alternative to Windows is more like it. Lets face it they are in the business of making money and the x86 market is too large to ignore.

I have been a FreeBSD user for over 6 years and love it as a server operating system, but I just refuse to use it on the desktop because I lack the apps. Instead I continue to use windows simply due to my legacy investment in software. Although with MACR DEVNET, I may switch to OSX when my I renew my license.

I recently deployed a project using FreeBSD. We clustered 3 servers running Jabber, 2 servers handle socket connections and the other server handles Jabber protocol and the user database. Currently the system supports 16,000 concurrent users as the socket servers can maintain 8,000 connections apiece using kqueue events on FreeBSD. The system is easy to scale as we simply add more socket servers to the cluster and add them into the load balancer. The 3 servers have been running for 10 months straight without a reboot, you sure can’t do that with windows!

Personally I think apple will release to x86 as soon as OSX achieves critical mass for applications. They cannot remain in a small niche OS market forever and the x86 architecture is in desperate need of a solid visual operating system.

cheers,

ted ;)

Stored Procedures in ASR Remoting


It seems that you can seamlessly integrate stored procedure calls with ActionScript Remoting. At first I was a bit skeptical that this would work, but some engineer at MM knew what they were doing. Here is a simple ASR remoting function using a stored procedure:

function getsystem(o){

// create a stored procedure call as a string

var sql = ‘sp_GetVersionInfo @id=’ + o.get(‘id’)

//execute the data via CF.query()

var ret = CF.query(“data001″,sql)

//return the sql result set to remoting

return ret

}

We are using SQL Server 2000 and ColdFusion MX. The database ‘data001′ is defined in the CF admin. Passing variables by name is a snap. Simply use the @{name} and use single quotes with stings (same as sql) and your all set. This makes using stored procedures easy.

Special thanks to Dave Gallerizzo at Figleaf for working through fine details to get this working.

Cheers,

ted ;)

Flash Usability – Pop-up blockers


I installed Google Toolbar in my browser and suddenly a majority of Flash sites don’t work!

When you designed your site, you put the core of your content into a pop-up and now I can’t see it without pressing CTRL usually on the 3rd or 4th time! Actually I don’t even realize that you have content on your site unless I catch the cursor change denoting a blocked site.

Google Toolbar – Pop-Up Blocker

Please switch your site from JavaScript POP-UP to Inline Flash.

Cheers,

Ted ;)

Non-XML over XMLSocket for F5-F7 Players


Although XMLSocket implies the use of XML, it is not required. The key to XMLSocket messaging is delimiting using Null bytes or ”. Using this technique you can avoid the xml parsing delay and use a string or binary encoding over an XMLSocket. The results are simply fantastic and speeds up system performance by a factor of 5 at a minimum for both client and server. For game use this is essential.

This requires a server that understands the string / binary encoding, here is a small socket server implementation in python:

import socket

HOST = ” # Symbolic name meaning the local host

PORT = 5222 # Arbitrary non-privileged port

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.bind((HOST, PORT))

s.listen(1)

conn, addr = s.accept()

print ‘Connected by’, addr

while 1:

data = conn.recv(1024)

data = data[0:len(data)-1]

if not data: break

print “Data received:”,data,” “,len(data)

if data == ‘foo’:

print “Data sent:bar”

conn.send(‘bar’)

break

On the client side, you use the following to avoid the XML parser:

x = new XMLSocket()

x.onConnect = function(success){

trace(‘onConnect ‘+success)

x.send(‘foo’)

}

x.onData = function(x){

trace(‘onData ‘+x)

if(x == ‘bar’){ trace(‘bar message!’)

}

x.connect(‘localhost’,5222)

The key is in using the onData event vs the onXML event. onData receives a string and onXML receives an XML object. Using onData avoids the XML parser on the client allowing you to use simple string parsing to execute a named function with arguments.

On a current project we are using this technique to render information to screen. The encoding pattern is very simple and supports 3 datatypes(number, string, hex) using space as a delimiter. These values are passed as follows:

x.send(‘onglyph 23 34 x394393 donut’)

The server receives:

‘onglyph 23 34 x394393 donut’

This is translated to a function call:

onglyph(23,34, ‘x394393′ , ‘donut’ )

The results of this function are then returned to the client in the same encoded format.

Although we don’t use XML as a whole, that doesn’t exclude it from being used as an argument. As XML is just a string, any argument in this encoding can easily be replaced by a XML document. Win, Win for structured data! ;)

Especially in regard to game use, this format is very small, very fast, and very efficient on both the client and server. We have seen great improvements in the performance by using this format. It is also very bandwidth friendly as the message size shrinks dramatically without XML encoding.

Enjoy,

Ted ;)