Obviously more details would be helpful, but I'll forward this to Matthew so he can look at the general approach and make sure it's consistent with the rest of the framework.

2 items about naming:

1. I don't think we should include the version number in the name. If we want to call out the versions supported, we can do that in docs.
2. The convention is that all words- including acronyms- are Capital Cased. It might seem weird; I think this convention was borrowed from the PEAR project.

This would result in the component name 'Zend_Amf'.

Thanks.
,Wil

A couple things to note – you may be moving in these directions already, but better to make sure early.

First, use request/response objects in the design. This will facilitate unit testing, as well as provide an easy point of customization for end-user developers. Additionally, this leaves the server handling only the details of dispatching the request; the request can handle deserializing the request payload, and the response can serialize the response payload.

This leads to my second point: naming. Do not include the protocol version in the component name. Instead, this can be handled in the request and response objects: Zend_Amf_Request_Version3, etc. Alternately, the request/response objects can auto-detect the version based on the request provided; this latter method is used by Zend_Json_Server in detecting JSON-RPC request versions (see the implementation in the current incubator for an example).

I agree on the protocol version in the name comments. Note that in order to correctly support an AMF request from the Flash Player that you must implement both AMF 0 and AMF 3 as all requests start out in AMF 0 and only switch to AMF 3 on the first complex object encountered for a header value or message body.

I'm not familiar with the magic referred to in the spec, but it would be nice to see some guesses at what the complete API will look like to users for this module.

The type mapping table would be clearer if shown in a formatted table with columns. I didn't see integer and double types mentioned in the list but I'd say they're mandatory.

Do you have any thoughts on what you'll do with IExternalizable types in PHP?

I think more detail is needed on how users will opt-in to which classes (and potentially methods) will be accessible via this component. There are hints as to usages of setClass() and addFunction()... does this mean one Zend_AMF_Server instance per class to be exposed as a service?

Will users be able to write custom serializers/deserializers for future versions of AMF? Perhaps even supporting AMFX (an XML representation of AMF used by Flex/BlazeDS's HTTPChannel)?

Speaking of BlazeDS considerations, will Zend understand and return BlazeDS "Messages" to the client or will it be simpler Flash Remoting style client libraries that will communicate with this kind of server?

This may be covered by another Zend module, but more information on how a Flash client authenticates would be useful. Can you apply roles based security to restrict who can call a particular remote object?

What about logging/debugging? Will you be able to enable debug logging to try and figure out what raw AMF data is being received/sent?

Peter,

To conform more with the way other Zend frameworks have been implemented I am using the Value and Value types for all marker types.

I do not have any idea how to deal with IExternalizable. I have seen how people have done it in Java and Python and could probably work from there.

I have added example instantiation code. I am having issues with just adding name spaces but have a question out the mailing list.

The goal is there is enough architecture in the Zend_Amf/Value.php class that people can add there own marker type handlers in as long as we know the byte definition for the marker type.

I have little to know documentation for how to implement messaging. I am not even sure where in the AMF stack it says that it is a "message"

Authentication from the AMF header needs to then run against Zend_Acl for authorization. I going to have to familiarise myself with Zend_Acl but it is where I was going to go as soon as I had all the serializers completed.

I am using Zend_Log right now for debugging. It is a pretty slick API. However I had no intentions of adding the functionality for raw AMF package, header, Body inspection. Is this something that you think would be useful. It is basically required for doing development on this addition to the framework but I am not sure Flex developers would find it useful. Most people use charles or service capture for debugging but I would like to know your thoughts?

Peter thanks for the links. I will look into them right away. Also let me do some investigation on IExternalizable.

Peter,

Please don't beat me up. After reading through the live docs I can't think of when I would use IExternalizable that I would not just use the meta data tag [Transient]. Any chance you have a URL to a use case so that I can better understand it. I always love learning new things about Flex!

I will look through some of the blazeDS code to see where they are doing logging and construct something similar.

What we'd like to see here added:
1. More use-cases, explaining how you talk to AMF - including passing data both ways and calling methods.
2. Detailed explanation on data type handling - how types are mapped into PHP and from PHP to AMF, especially dealing with higher-order types like Date that may or may not have PHP classes representing them. E.g., do we store Date as AMF_Date, DateTime or timestamp, how we create date value to send to AMF, etc.
3. What are AMF3 types - how they are different, is there any reason for the PHP user to distinguish them and if yes, when? Is there any automatic way to handle them so PHP programmer wouldn't be concerned about them too much if he doesn't need to?

Hi wade,

The code block in the use cases section looks good. It looks a lot like other service classes, so that should keep the learning curve down : )

A few questions, suggestions:

• What are the specific requirements for this component? What must it be able to do and what not?
• Could you give an use-case where this component is integrated in the MVC structure?
• What about AMF0 support?

As for the mapping of AS -> PHP; The uint would probably become a regular PHP integer.
An Object could probably become a stdClass or ArrayObject instead of an associative array.

• Jurriën