amfphp-cvs Mailing List for Amfphp

Hi everyone,
I've had two separate people complain about problems with the mailing list
like not receiving or not being able to post or whatever. Furthermore, the
interface for managing it sucks, browsing the archive is insanely slow...
So I suggest we move any further team discussions to the forum.
I've created a new one especially for this:
https://sourceforge.net/projects/amfphp/forums/forum/1111094
It's public for now, I hope it can stay that way.
Please monitor it so that you get a notification regarding the messages
there. Our discussions on this list have started to prove fruitful, let's
try to keep this going!
To get started I did a first post
https://sourceforge.net/projects/amfphp/forums/forum/1111094/topic/3615460
Ariel

Sounds good.

--Joey

On Mar 15, 2010, at 12:55 PM, Ariel Sommeria wrote:

> I see what you mean about the fitting. However I don't think we need a lockdown, we have a tag for that. How about like this:
> Now that we've got the ideas down, it's really not much time to crank out this plugin system with an example to get the ball rolling. so I can get started and we can start toying with it, and release it once we're happy as a "developer preview", ie, not in the main distribution for the time being. We can start getting user feedback on the thing, because plugins are going to be comunity driven and that takes time.
> In the meantime you guys can throw around some ideas about the rewrite, because your ideas and apparently your knowledge of the code base are clearer than mine. We can then take that as a starting point for a spec. 
> In that way the two processes can move along independently.
> Ariel
> 
> 
> On Mon, Mar 15, 2010 at 6:34 PM, Joey Parrish <jpa...@la...> wrote:
> I think you're right that we should have a collaborative process and a spec before a rewrite.  I'm just of the opinion that a plugin system fits better with a rewritten version than with the current one.  I'd say the current version should be put into the best, most stable state, then locked down so that we can start a spec for the rewrite.
> 
> Anyway, that's my two cents.
> 
> --Joey

I see what you mean about the fitting. However I don't think we need a
lockdown, we have a tag for that. How about like this:
Now that we've got the ideas down, it's really not much time to crank out
this plugin system with an example to get the ball rolling. so I can get
started and we can start toying with it, and release it once we're happy as
a "developer preview", ie, not in the main distribution for the time being.
We can start getting user feedback on the thing, because plugins are going
to be comunity driven and that takes time.
In the meantime you guys can throw around some ideas about the rewrite,
because your ideas and apparently your knowledge of the code base are
clearer than mine. We can then take that as a starting point for a spec.
In that way the two processes can move along independently.
Ariel


On Mon, Mar 15, 2010 at 6:34 PM, Joey Parrish <jpa...@la...>wrote:

> I think you're right that we should have a collaborative process and a spec
> before a rewrite.  I'm just of the opinion that a plugin system fits better
> with a rewritten version than with the current one.  I'd say the current
> version should be put into the best, most stable state, then locked down so
> that we can start a spec for the rewrite.
>
> Anyway, that's my two cents.
>
> --Joey
>
> On Mar 12, 2010, at 4:59 AM, Ariel Sommeria wrote:
>
> Ok for PHP5.
> Ok I see you're getting all excited about doing a rewrite. You're saying
> it's not such a mammoth task. Allow me to be skeptical. If somebody wants to
> give me a spec and an estimation then I can start to consider it. I agree
> that a rewrite would be in order, but could we get a new version out first?
> The goals for the new version are(my take, please feel free to mess with
> the list):
> - plugins (doh!)
> - the revamped service browser
> - a plugin for authentication
> Once we've done thatwe can make a release, stating that we're planning a
> rewrite so don't get too bogged down on the hooks because they're probably
> going to move a lot.
> I think it's less ambitious to start like that than to jump in to a
> rewrite. Once we get the release out the door, it will be a proof that we
> can work together and get shit done, and it will establish a process for
> discussion of specs, deciding who will do what etc. Without that process, I
> don't think we can collaboratively pull a rewrite off. We could just say
> "Hey Joey, you seem to be good at this, could you just do a rewrite and tell
> us when it's done and what it does and make all the design decisions
> yourself and please feel free to jump in and start coding without a clue
> where you're heading" (ok a bit extreme, but you get the idea). But you'll
> probably agree that that's probably not the way to go.
> What do you think?
> Ariel
>
> On Wed, Mar 10, 2010 at 11:25 PM, Joey Parrish <jpa...@la...>wrote:
>
>>
>> On Mar 10, 2010, at 3:48 PM, Danny Kopping wrote:
>>
>> Hi guys
>>
>> Sorry i'm joining in the conversation so late. I've been caught up by a
>> number of things lately.
>> Ok, i think that the ideas that you guys have been throwing around are
>> great! I think we need to keep a couple of things in mind:
>>
>> 1. It's not practical to support PHP4 anymore. Any developer worth his
>> salt has moved over to PHP5 and any organization still using PHP4 is insane.
>> We need to take advantage of PHP5's wonderful new features and we must
>> remember that we can never please all of the people all of the time.
>>
>>
>> Hooray!
>>
>>
>> 2. Staying with the ethos of AMFPHP, we can make the core as hardcore as
>> we please, but the implementation must be dead simple. Whatever we
>> eventually settle on, it has to be clear and concise, not cerebral.
>>
>>
>> I agree.
>>
>> 3. What would be best for AMFPHP? Should we hack away at the already
>> convoluted core, or should we assemble a team to re-code AMFPHP from
>> scratch, or at least parts of it? My vote is for the latter... Sure, we're
>> not going to rewrite things like AMFBaseDeserializer or anything like that,
>> but i do feel (strongly) that the general flow of the system could be
>> neater, more concise, more structured. This would not be such a mammoth
>> task...
>>
>>
>> I agree, let's rewrite the core.  We should keep the encoder/decoder
>> implementations, but I think even the envelope and exception classes need to
>> be re-done.
>>
>> --Joey
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> amfphp-cvs mailing list
>> amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
>
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>

I think you're right that we should have a collaborative process and a spec before a rewrite.  I'm just of the opinion that a plugin system fits better with a rewritten version than with the current one.  I'd say the current version should be put into the best, most stable state, then locked down so that we can start a spec for the rewrite.

Anyway, that's my two cents.

--Joey

On Mar 12, 2010, at 4:59 AM, Ariel Sommeria wrote:

> Ok for PHP5.
> Ok I see you're getting all excited about doing a rewrite. You're saying it's not such a mammoth task. Allow me to be skeptical. If somebody wants to give me a spec and an estimation then I can start to consider it. I agree that a rewrite would be in order, but could we get a new version out first? 
> The goals for the new version are(my take, please feel free to mess with the list):
> - plugins (doh!)
> - the revamped service browser
> - a plugin for authentication
> Once we've done thatwe can make a release, stating that we're planning a rewrite so don't get too bogged down on the hooks because they're probably going to move a lot. 
> I think it's less ambitious to start like that than to jump in to a rewrite. Once we get the release out the door, it will be a proof that we can work together and get shit done, and it will establish a process for discussion of specs, deciding who will do what etc. Without that process, I don't think we can collaboratively pull a rewrite off. We could just say "Hey Joey, you seem to be good at this, could you just do a rewrite and tell us when it's done and what it does and make all the design decisions yourself and please feel free to jump in and start coding without a clue where you're heading" (ok a bit extreme, but you get the idea). But you'll probably agree that that's probably not the way to go. 
> What do you think?
> Ariel
> 
> On Wed, Mar 10, 2010 at 11:25 PM, Joey Parrish <jpa...@la...> wrote:
> 
> On Mar 10, 2010, at 3:48 PM, Danny Kopping wrote:
> 
>> Hi guys
>> 
>> Sorry i'm joining in the conversation so late. I've been caught up by a number of things lately.
>> Ok, i think that the ideas that you guys have been throwing around are great! I think we need to keep a couple of things in mind:
>> 
>> 1. It's not practical to support PHP4 anymore. Any developer worth his salt has moved over to PHP5 and any organization still using PHP4 is insane. We need to take advantage of PHP5's wonderful new features and we must remember that we can never please all of the people all of the time.
> 
> Hooray!
> 
> 
>> 2. Staying with the ethos of AMFPHP, we can make the core as hardcore as we please, but the implementation must be dead simple. Whatever we eventually settle on, it has to be clear and concise, not cerebral.
> 
> I agree.
> 
>> 3. What would be best for AMFPHP? Should we hack away at the already convoluted core, or should we assemble a team to re-code AMFPHP from scratch, or at least parts of it? My vote is for the latter... Sure, we're not going to rewrite things like AMFBaseDeserializer or anything like that, but i do feel (strongly) that the general flow of the system could be neater, more concise, more structured. This would not be such a mammoth task...
> 
> I agree, let's rewrite the core.  We should keep the encoder/decoder implementations, but I think even the envelope and exception classes need to be re-done.
> 
> --Joey
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs

Ok for PHP5.
Ok I see you're getting all excited about doing a rewrite. You're saying
it's not such a mammoth task. Allow me to be skeptical. If somebody wants to
give me a spec and an estimation then I can start to consider it. I agree
that a rewrite would be in order, but could we get a new version out first?
The goals for the new version are(my take, please feel free to mess with the
list):
- plugins (doh!)
- the revamped service browser
- a plugin for authentication
Once we've done thatwe can make a release, stating that we're planning a
rewrite so don't get too bogged down on the hooks because they're probably
going to move a lot.
I think it's less ambitious to start like that than to jump in to a rewrite.
Once we get the release out the door, it will be a proof that we can work
together and get shit done, and it will establish a process for discussion
of specs, deciding who will do what etc. Without that process, I don't think
we can collaboratively pull a rewrite off. We could just say "Hey Joey, you
seem to be good at this, could you just do a rewrite and tell us when it's
done and what it does and make all the design decisions yourself and please
feel free to jump in and start coding without a clue where you're heading"
(ok a bit extreme, but you get the idea). But you'll probably agree that
that's probably not the way to go.
What do you think?
Ariel

On Wed, Mar 10, 2010 at 11:25 PM, Joey Parrish <jpa...@la...>wrote:

>
> On Mar 10, 2010, at 3:48 PM, Danny Kopping wrote:
>
> Hi guys
>
> Sorry i'm joining in the conversation so late. I've been caught up by a
> number of things lately.
> Ok, i think that the ideas that you guys have been throwing around are
> great! I think we need to keep a couple of things in mind:
>
> 1. It's not practical to support PHP4 anymore. Any developer worth his salt
> has moved over to PHP5 and any organization still using PHP4 is insane. We
> need to take advantage of PHP5's wonderful new features and we must remember
> that we can never please all of the people all of the time.
>
>
> Hooray!
>
>
> 2. Staying with the ethos of AMFPHP, we can make the core as hardcore as we
> please, but the implementation must be dead simple. Whatever we eventually
> settle on, it has to be clear and concise, not cerebral.
>
>
> I agree.
>
> 3. What would be best for AMFPHP? Should we hack away at the already
> convoluted core, or should we assemble a team to re-code AMFPHP from
> scratch, or at least parts of it? My vote is for the latter... Sure, we're
> not going to rewrite things like AMFBaseDeserializer or anything like that,
> but i do feel (strongly) that the general flow of the system could be
> neater, more concise, more structured. This would not be such a mammoth
> task...
>
>
> I agree, let's rewrite the core.  We should keep the encoder/decoder
> implementations, but I think even the envelope and exception classes need to
> be re-done.
>
> --Joey
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>

On Mar 10, 2010, at 3:48 PM, Danny Kopping wrote:

> Hi guys
> 
> Sorry i'm joining in the conversation so late. I've been caught up by a number of things lately.
> Ok, i think that the ideas that you guys have been throwing around are great! I think we need to keep a couple of things in mind:
> 
> 1. It's not practical to support PHP4 anymore. Any developer worth his salt has moved over to PHP5 and any organization still using PHP4 is insane. We need to take advantage of PHP5's wonderful new features and we must remember that we can never please all of the people all of the time.

Hooray!

> 2. Staying with the ethos of AMFPHP, we can make the core as hardcore as we please, but the implementation must be dead simple. Whatever we eventually settle on, it has to be clear and concise, not cerebral.

I agree.

> 3. What would be best for AMFPHP? Should we hack away at the already convoluted core, or should we assemble a team to re-code AMFPHP from scratch, or at least parts of it? My vote is for the latter... Sure, we're not going to rewrite things like AMFBaseDeserializer or anything like that, but i do feel (strongly) that the general flow of the system could be neater, more concise, more structured. This would not be such a mammoth task...

I agree, let's rewrite the core.  We should keep the encoder/decoder implementations, but I think even the envelope and exception classes need to be re-done.

--Joey

Hi guys

Sorry i'm joining in the conversation so late. I've been caught up by a
number of things lately.
Ok, i think that the ideas that you guys have been throwing around are
great! I think we need to keep a couple of things in mind:

1. It's not practical to support PHP4 anymore. Any developer worth his salt
has moved over to PHP5 and any organization still using PHP4 is insane. We
need to take advantage of PHP5's wonderful new features and we must remember
that we can never please all of the people all of the time.

2. Staying with the ethos of AMFPHP, we can make the core as hardcore as we
please, but the implementation must be dead simple. Whatever we eventually
settle on, it has to be clear and concise, not cerebral.

3. What would be best for AMFPHP? Should we hack away at the already
convoluted core, or should we assemble a team to re-code AMFPHP from
scratch, or at least parts of it? My vote is for the latter... Sure, we're
not going to rewrite things like AMFBaseDeserializer or anything like that,
but i do feel (strongly) that the general flow of the system could be
neater, more concise, more structured. This would not be such a mammoth
task...

Your thoughts?

I think php 5 should be fine, I started out supporting php 4 with 
CubeHenge and there were some limitations that prompted me to drop 4.  
Since then I've setup a number of installs for clients, shared hosting 
worst case scenario sort of environments and such, all had php 5 
available and I haven't run into any issues from that angle.

It would stand to reason that anyone looking for these new features 
would be setting up a new application environment and if they have to do 
that with php 4 I'd be pretty surprised.



On 3/10/2010 3:24 PM, Joey Parrish wrote:
>
> On Mar 10, 2010, at 11:04 AM, Ariel Sommeria wrote:
>>
>>>     Why do you guys want to call addHook with these params:
>>>     (AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));
>>>
>>>     Wouldn't
>>>     (AMFPHP_SERVICE_RETURN, mangleServiceOutputData);
>>>
>>>     be enough? Why a this? and why in an array?
>>
>>     Because that's the syntax for a member function callback in php.
>>      Either array($object, $methodName) or array($className,
>>     $staticMethodName).  See
>>     http://php.net/manual/en/function.call-user-func.php for
>>     documentation.  My point was to avoid using global methods which
>>     could have namespace conflicts with other plugins, especially for
>>     common tasks where people are just likely to use the same simple
>>     names for functions.
>>
>> ok, point taken. I see in the doc that there are some limitations 
>> regarding php versions. It would be good to stay compatible with 5.0. 
>> Will this be ok?
>
>
> I must have missed that part of the doc.  What are the limitations?
>
> As far as php compatibility, I'd be happy enough to support php5 and 
> drop php4.  If anybody on list is still stuck with php4, we can always 
> try to keep that working, too, I guess.  I've been on php5 forever it 
> seems, and php6 is coming out (I think) soon.  If we have to start 
> supporting php6 in a couple months, I'd rather not also be reaching 
> back to support php4 at the same time.
>
> I dunno.  Maybe I'm being too picky.
>
> --Joey
>
>
> *
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14530
> http://www.pctools.com/spyware-doctor-antivirus/ 
> <http://www.pctools.com/en/spyware-doctor-antivirus/>
> *
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14530
> http://www.pctools.com/en/spyware-doctor-antivirus/
>    
>
>
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>
>
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14530
> http://www.pctools.com/en/spyware-doctor-antivirus/
>    

On Mar 10, 2010, at 11:04 AM, Ariel Sommeria wrote:
>> Why do you guys want to call addHook with these params:
>> (AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));
>> 
>> Wouldn't 
>> (AMFPHP_SERVICE_RETURN, mangleServiceOutputData);
>> 
>> be enough? Why a this? and why in an array?
> 
> Because that's the syntax for a member function callback in php.  Either array($object, $methodName) or array($className, $staticMethodName).  See http://php.net/manual/en/function.call-user-func.php for documentation.  My point was to avoid using global methods which could have namespace conflicts with other plugins, especially for common tasks where people are just likely to use the same simple names for functions.
> 
> ok, point taken. I see in the doc that there are some limitations regarding php versions. It would be good to stay compatible with 5.0. Will this be ok? 


I must have missed that part of the doc.  What are the limitations?

As far as php compatibility, I'd be happy enough to support php5 and drop php4.  If anybody on list is still stuck with php4, we can always try to keep that working, too, I guess.  I've been on php5 forever it seems, and php6 is coming out (I think) soon.  If we have to start supporting php6 in a couple months, I'd rather not also be reaching back to support php4 at the same time.

I dunno.  Maybe I'm being too picky.

--Joey

On Wed, Mar 10, 2010 at 5:27 PM, Joey Parrish <jpa...@la...>wrote:

> On Mar 10, 2010, at 7:22 AM, Ariel Sommeria wrote:
>
> These are just ideas for plugins I'm throwing around, so Joey if you're
> interested in beoing able to hook a certain plugin idea, we should work it
> out. What I figure is that once the basics are sorted out, we start with a
> few hooks needed to get the ball rolling, and if developers need an extra
> hook we add it in. The beauty of plugins is that we don't need to mess with
> branches.
> On replacing stages: sure why not, but I think that warrants a separate
> discussion
> So, if the broad strokes are ok, let's talk about syntax and parameters and
> naming and such.
> Agree, the call to addHook is through a static class. Amfphp is way too
> general a name for it. I've been talking with Alexandre Hoyau from Silex
> labs and he suggested we use his hook_manager class. I think it fits and is
> more descriptive and precise. Take a look:
>
> http://silex.svn.sourceforge.net/viewvc/silex/trunk/silex_server/cgi/includes/hook_manager.php?view=markup
>
>
> I guess I didn't think it was complex enough to import another project, but
> that code looks fine to me.  I have no serious objections.
>
> not the project, just the file, but ok

>
> Why do you guys want to call addHook with these params:
> (AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));
>
> Wouldn't
> (AMFPHP_SERVICE_RETURN, mangleServiceOutputData);
>
> be enough? Why a this? and why in an array?
>
>
> Because that's the syntax for a member function callback in php.  Either
> array($object, $methodName) or array($className, $staticMethodName).  See
> http://php.net/manual/en/function.call-user-func.php for documentation.
>  My point was to avoid using global methods which could have namespace
> conflicts with other plugins, especially for common tasks where people are
> just likely to use the same simple names for functions.
>
> ok, point taken. I see in the doc that there are some limitations regarding
php versions. It would be good to stay compatible with 5.0. Will this be ok?


> How about the call from the hook manager to mangleServiceOutputData?
>
>
> I was originally thinking of a set of common amfphp functions that are
> available from anywhere inside an amfphp execution environment.  For
> example, managing hooks.  That's why I was using AmfPhp::addHook() in my
> examples.  The callback would be done like this:
>
> $data = "whatever the data is, i dunno.";
> foreach ($callback_list[$hook_name] as $callback) {
> $args = array($data, blah, blah, blah);
>  $data = call_user_func_array($callback, $args);
> }
> # continue processing the now filtered and maybe altered $data.
>
yes, I was thinking along those lines too. I agree on the "set of common
amfphp functions", but I still think they need a more descriptive name.
Otherwise AmfPhp would quickly end up with a mishmash of unrelated stuff.
Hence Hook Manager.

>
> Would the parameters be specific to the hook? Or is there a standard way of
> passing things that would fit?
>
>
> I suggest having each hook accept certain parameters, which are documented
> as that hook's API.  Then, each plugin class has a static variable that
> specifies what API version it implements.  If a plugin is used with a
> version of amfphp which has an incompatible version, that plugin gets
> skipped and a warning is logged.
>
> The API version could just be a simple number, incremented each time the
> arguments were changed for a hook.  I expect this wouldn't happen often once
> a release-quality version of amfphp 2 comes out.
>
> That's a great idea. I hear from my wordpress fellows that the API is
always changing and that it breaks the code without much warning.

> A hook could be called systematically with all the arguments of the
> enclosing function for example. That's the way I would do it in AS3 for
> example
>
> mangleServiceOutputData(args).
> It makes the learning curve lighter I find.
> But I'm not sure that that's possible in PHP(I looked but didn't find).
> Joey, maybe?
> And independantly, is it such a good idea?
>
>
> I don't know if I see the benefit, but it's easy enough to do.  You can use
> func_get_args() to get an array of the arguments to the current function.
>
> I could easily see a situation wherein you would not want your hooks to
> have access to everything in the function.  Some private data perhaps is
> passed around inside the framework class and you don't want anybody
> accessing.  Or maybe you have data that was only created in this function
> that must be passed to the hook.  Then, if you only pass the calling
> function's args, you don't have enough info passed to the hook.
>
> I tend to think that each hook should be given a single piece of data which
> it is intended to modify, and the modified version is returned from the
> hook.  The hook may also receive other parameters which are useful to it,
> but which it is not intended to modify.  Let me see if I can come up with an
> example...
>
> class InputStage
> {
> function getAmfInput($inputDataStream, $length)
> {
> $amfData = fread($inputDataStream, $length);
>  // call amf input hooks
> foreach ($this->amfInputHooks as $hook) {
> $args = array($amfData, $someOtherData);
>  $amfData = call_user_func_array($hook, $args);
> }
> return $amfData;
>  }
> function decodeAmf($amfData)
> {
> if ($this->replacementDecoder !== null) {
>  // use replacement decoder
> return call_user_func_array($this->replacementDecoder, array($amfData));
> } else {
>  // use built-in decoder
> $decoder = new AmfPhpDecoder();
> return $decoder->decode($amfData);
>  }
> }
> function goDoYourThing()  // I'm out of intelligent names for today.
>  Sorry.
>  {
> $fp = fopen("php://input");
> return $this->decodeAmf($this->getAmfInput($fp,
> $_SERVER['whatever_var_holds_input_length']));
>  }
> }
>
> --Joey
>
>
> ok, that just means that each hook has to have a well documented api, not
just a name.

>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>

On Mar 10, 2010, at 7:22 AM, Ariel Sommeria wrote:

> These are just ideas for plugins I'm throwing around, so Joey if you're interested in beoing able to hook a certain plugin idea, we should work it out. What I figure is that once the basics are sorted out, we start with a few hooks needed to get the ball rolling, and if developers need an extra hook we add it in. The beauty of plugins is that we don't need to mess with branches. 
> On replacing stages: sure why not, but I think that warrants a separate discussion
> So, if the broad strokes are ok, let's talk about syntax and parameters and naming and such.
> Agree, the call to addHook is through a static class. Amfphp is way too general a name for it. I've been talking with Alexandre Hoyau from Silex labs and he suggested we use his hook_manager class. I think it fits and is more descriptive and precise. Take a look:
> http://silex.svn.sourceforge.net/viewvc/silex/trunk/silex_server/cgi/includes/hook_manager.php?view=markup 

I guess I didn't think it was complex enough to import another project, but that code looks fine to me.  I have no serious objections.


> Why do you guys want to call addHook with these params:
> (AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));
> 
> Wouldn't 
> (AMFPHP_SERVICE_RETURN, mangleServiceOutputData);
> 
> be enough? Why a this? and why in an array?

Because that's the syntax for a member function callback in php.  Either array($object, $methodName) or array($className, $staticMethodName).  See http://php.net/manual/en/function.call-user-func.php for documentation.  My point was to avoid using global methods which could have namespace conflicts with other plugins, especially for common tasks where people are just likely to use the same simple names for functions.

> How about the call from the hook manager to mangleServiceOutputData?

I was originally thinking of a set of common amfphp functions that are available from anywhere inside an amfphp execution environment.  For example, managing hooks.  That's why I was using AmfPhp::addHook() in my examples.  The callback would be done like this:

$data = "whatever the data is, i dunno.";
foreach ($callback_list[$hook_name] as $callback) {
	$args = array($data, blah, blah, blah);
	$data = call_user_func_array($callback, $args);
}
# continue processing the now filtered and maybe altered $data.

> Would the parameters be specific to the hook? Or is there a standard way of passing things that would fit? 

I suggest having each hook accept certain parameters, which are documented as that hook's API.  Then, each plugin class has a static variable that specifies what API version it implements.  If a plugin is used with a version of amfphp which has an incompatible version, that plugin gets skipped and a warning is logged.

The API version could just be a simple number, incremented each time the arguments were changed for a hook.  I expect this wouldn't happen often once a release-quality version of amfphp 2 comes out.

> A hook could be called systematically with all the arguments of the enclosing function for example. That's the way I would do it in AS3 for example 
>  
> mangleServiceOutputData(args). 
> It makes the learning curve lighter I find. 
> But I'm not sure that that's possible in PHP(I looked but didn't find). Joey, maybe?
> And independantly, is it such a good idea?

I don't know if I see the benefit, but it's easy enough to do.  You can use func_get_args() to get an array of the arguments to the current function.

I could easily see a situation wherein you would not want your hooks to have access to everything in the function.  Some private data perhaps is passed around inside the framework class and you don't want anybody accessing.  Or maybe you have data that was only created in this function that must be passed to the hook.  Then, if you only pass the calling function's args, you don't have enough info passed to the hook.

I tend to think that each hook should be given a single piece of data which it is intended to modify, and the modified version is returned from the hook.  The hook may also receive other parameters which are useful to it, but which it is not intended to modify.  Let me see if I can come up with an example...

class InputStage
{
	function getAmfInput($inputDataStream, $length)
	{
		$amfData = fread($inputDataStream, $length);
		// call amf input hooks
		foreach ($this->amfInputHooks as $hook) {
			$args = array($amfData, $someOtherData);
			$amfData = call_user_func_array($hook, $args);
		}
		return $amfData;
	}
	function decodeAmf($amfData)
	{
		if ($this->replacementDecoder !== null) {
			// use replacement decoder
			return call_user_func_array($this->replacementDecoder, array($amfData));
		} else {
			// use built-in decoder
			$decoder = new AmfPhpDecoder();
			return $decoder->decode($amfData);
		}
	}
	function goDoYourThing()  // I'm out of intelligent names for today.  Sorry.
	{
		$fp = fopen("php://input");
		return $this->decodeAmf($this->getAmfInput($fp, $_SERVER['whatever_var_holds_input_length']));
	}
}

--Joey

These are just ideas for plugins I'm throwing around, so Joey if you're
interested in beoing able to hook a certain plugin idea, we should work it
out. What I figure is that once the basics are sorted out, we start with a
few hooks needed to get the ball rolling, and if developers need an extra
hook we add it in. The beauty of plugins is that we don't need to mess with
branches.
On replacing stages: sure why not, but I think that warrants a separate
discussion
So, if the broad strokes are ok, let's talk about syntax and parameters and
naming and such.
Agree, the call to addHook is through a static class. Amfphp is way too
general a name for it. I've been talking with Alexandre Hoyau from Silex
labs and he suggested we use his hook_manager class. I think it fits and is
more descriptive and precise. Take a look:
http://silex.svn.sourceforge.net/viewvc/silex/trunk/silex_server/cgi/includes/hook_manager.php?view=markup
Why do you guys want to call addHook with these params:
(AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));

Wouldn't
(AMFPHP_SERVICE_RETURN, mangleServiceOutputData);

be enough? Why a this? and why in an array?

How about the call from the hook manager to mangleServiceOutputData?

Would the parameters be specific to the hook? Or is there a standard way of
passing things that would fit?

A hook could be called systematically with all the arguments of the
enclosing function for example. That's the way I would do it in AS3 for
example

mangleServiceOutputData(args).
It makes the learning curve lighter I find.
But I'm not sure that that's possible in PHP(I looked but didn't find).
Joey, maybe?
And independantly, is it such a good idea?

Ariel



On Wed, Mar 10, 2010 at 5:12 AM, Joey Parrish <jpa...@la...>wrote:

> On Mar 9, 2010, at 9:54 PM, Ryan T. Graff wrote:
>
> > So from my perspective I would say put a priority on being able to read
> > and manipulate the input and output to and from a service call with a
> > plug-in.
> >
> > And make a branch that deals with swapping out encode/decode engines. I
> > think exploring other translators to see if what's already in AMFPHP is
> > the best or not is a good idea, but I think most people won't even toy
> > with it, this is sort of a hardcore thing that could be offered to a
> > more demanding crowd of developers.
> >
>
> My company and I are in that crowd.  :)  And I'm happy to contribute to the
> effort.
>
> FWIW, here's a link to performance comparison of the current amfphp encoder
> vs. the amfext C encoder:
>
>
> http://www.5etdemi.com/blog/archives/2007/01/amfphp-19-beta-2-ridiculously-faster/
>
> That encoder extension will eventually be reborn along-side amfphp, and the
> two will be well-suited to help validate each other's changes.
>
> --Joey
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>

On Mar 9, 2010, at 9:54 PM, Ryan T. Graff wrote:

> So from my perspective I would say put a priority on being able to read 
> and manipulate the input and output to and from a service call with a 
> plug-in.
> 
> And make a branch that deals with swapping out encode/decode engines. I 
> think exploring other translators to see if what's already in AMFPHP is 
> the best or not is a good idea, but I think most people won't even toy 
> with it, this is sort of a hardcore thing that could be offered to a 
> more demanding crowd of developers.
> 

My company and I are in that crowd.  :)  And I'm happy to contribute to the effort.

FWIW, here's a link to performance comparison of the current amfphp encoder vs. the amfext C encoder:

http://www.5etdemi.com/blog/archives/2007/01/amfphp-19-beta-2-ridiculously-faster/

That encoder extension will eventually be reborn along-side amfphp, and the two will be well-suited to help validate each other's changes.

--Joey

So from my perspective I would say put a priority on being able to read 
and manipulate the input and output to and from a service call with a 
plug-in.

And make a branch that deals with swapping out encode/decode engines. I 
think exploring other translators to see if what's already in AMFPHP is 
the best or not is a good idea, but I think most people won't even toy 
with it, this is sort of a hardcore thing that could be offered to a 
more demanding crowd of developers.


On 3/9/2010 2:20 PM, Joey Parrish wrote:
> On Mar 9, 2010, at 1:00 PM, Ryan T. Graff wrote:
>
>    
>> So far I like the looks of this: "
>>
>> # alter the data coming out of a service method, before serialization.
>> AmfPhp::addHook(AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));
>>
>> "
>> And would like to see one for input too.
>>
>>      
> Yeah, naturally.  I don't consider my examples to be an exhaustive list of what we would want to be able to hook into.
>
>
>    
>> As far as intercepting the AMF encoding, what could be done with that,
>> aside form just using a different engine, have people asked for this
>> sort of thing?
>>
>>      
>
> Right now there is hard-coded support for one alternative encoder.  A plugin system would just make it easier to try alternate implementations, which could result in the adoption of a faster one as the default.  It could also facilitate the verification/comparison of different encoders to make sure they all produce the right output.
>
> --Joey
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>
>
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14520
> http://www.pctools.com/en/spyware-doctor-antivirus/
>
>    

On Mar 9, 2010, at 1:00 PM, Ryan T. Graff wrote:

> So far I like the looks of this: "
> 
> # alter the data coming out of a service method, before serialization.
> AmfPhp::addHook(AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));
> 
> "
> And would like to see one for input too.
> 

Yeah, naturally.  I don't consider my examples to be an exhaustive list of what we would want to be able to hook into.


> As far as intercepting the AMF encoding, what could be done with that, 
> aside form just using a different engine, have people asked for this 
> sort of thing?
> 


Right now there is hard-coded support for one alternative encoder.  A plugin system would just make it easier to try alternate implementations, which could result in the adoption of a faster one as the default.  It could also facilitate the verification/comparison of different encoders to make sure they all produce the right output.

--Joey

So far I like the looks of this: "

# alter the data coming out of a service method, before serialization.
AmfPhp::addHook(AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));

"
And would like to see one for input too.

As far as intercepting the AMF encoding, what could be done with that, 
aside form just using a different engine, have people asked for this 
sort of thing?




On 3/9/2010 9:10 AM, Joey Parrish wrote:
> # alter the data coming out of a service method, before serialization.
> AmfPhp::addHook(AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));
>    

On Mar 9, 2010, at 3:07 AM, Ariel Sommeria wrote:

> I like the revised structure. So the hook registration would happen in the class constructor, right?
> some ideas:
> - some filters are optional, even non functional. If you look in core/amf/app/Filters.php there are some essential filters for serialization/deserialization, plus some dubious or non functional filters such as authentication. These filters could be shifted to plugins. In that way the core ones could be replaced for special purposes or temp bug fixing. For example Joey submitted a patch on the deserializing of bytearrays(correct me if I'm wrong Joey), and it will be in the next version. In the meantime, it could be a plugin. Authentication is currently non functional, so it could be thrown out and replaced by one or many plugins. We're working on something simple with Danny Kopping, but it might not be evolved enough for your tastes, so you could offer your "Allow" system as a plugin. 
> - I'm still trying to wrap my head around actions, but I'm sure there are some plugin things to be done there
> - a logging plugin. Actually, I would probably do this with filters. 
> - code generation in the service browser. It's not part of the service browser, and doesn't make sense as part of its core, but would be a nice thing to be able to integrate with it as a plugin. 
> 
> A filter plugin for example would have 3 functions.
> - your plugin class constructor, a call would look something like this:
> hook_manager.add_hook(GET_FILTERS, addMyFilterFunction)
> - addMyFilterFunction would get called when the filters are collected, and would be passed an array as parameter to which it would add your filter function.
> - the actual filter function myFilterFunction
> 
> Then when the filters are executed, your filter is too. 
> 

I think I like this way:
- your plugin class constructor would call something like:

# alter the AMF stream coming in.
AmfPhp::addHook(AMFPHP_AMF_INPUT, array(this, 'mangleAmfStream'));
# alter the location of a service after the decision has been made.
AmfPhp::addHook(AMFPHP_SERVICE_RESOLUTION, array(this, 'mangleServiceLocation'));
# alter the data coming out of a service method, before serialization.
AmfPhp::addHook(AMFPHP_SERVICE_RETURN, array(this, 'mangleServiceOutputData'));

- AmfPhp is a class with static members provided by the framework.
- your filters are added to various points in the processing chain when you call addHook.
- those calls are then passed data in some form and return data in the same form.
- your plugin could also call something like:

# use AmfExt for decoding AMF.
AmfPhp::replaceStage(AMFPHP_DESERIALIZE, 'amf_decode');
# use AmfExt for encoding AMF.
AmfPhp::replaceStage(AMFPHP_SERIALIZE, 'amf_encode');
# replace the logic that decides where a service lives.
AmfPhp::replaceStage(AMFPHP_SERVICE_LOOKUP, array(this, 'lookupServiceMethod'));

- now you can replace entire processing stages (say, for an AmfExt plugin) instead of just filtering data at various mid-points in processing.
- you could replace the serialization stage with XML encoding, then filter to change the HTTP content-type header, then you've got an XML gateway instead of an AMF gateway.


--Joey

I like the revised structure. So the hook registration would happen in the
class constructor, right?
some ideas:
- some filters are optional, even non functional. If you look in
core/amf/app/Filters.php there are some essential filters for
serialization/deserialization, plus some dubious or non functional filters
such as authentication. These filters could be shifted to plugins. In that
way the core ones could be replaced for special purposes or temp bug fixing.
For example Joey submitted a patch on the deserializing of
bytearrays(correct me if I'm wrong Joey), and it will be in the next
version. In the meantime, it could be a plugin. Authentication is currently
non functional, so it could be thrown out and replaced by one or many
plugins. We're working on something simple with Danny Kopping, but it might
not be evolved enough for your tastes, so you could offer your "Allow"
system as a plugin.
- I'm still trying to wrap my head around actions, but I'm sure there are
some plugin things to be done there
- a logging plugin. Actually, I would probably do this with filters.
- code generation in the service browser. It's not part of the service
browser, and doesn't make sense as part of its core, but would be a nice
thing to be able to integrate with it as a plugin.

A filter plugin for example would have 3 functions.
- your plugin class constructor, a call would look something like this:
hook_manager.add_hook(GET_FILTERS, addMyFilterFunction)
- addMyFilterFunction would get called when the filters are collected, and
would be passed an array as parameter to which it would add your filter
function.
- the actual filter function myFilterFunction

Then when the filters are executed, your filter is too.

How does that sound?
Ariel

On Mon, Mar 8, 2010 at 11:11 PM, Ryan T. Graff
<rya...@re...>wrote:

> I'm in agreement with Joey on this one, class structure is much cleaner.
>
> I would like to know more about what a plug-in would do, like a use case
> where:
>
> 1. A service is called, passing in data from the client
> 2. The plug-in executes
> 3. The data, (effected by the plug-in???), returns
>
> If I knew more 'real world' use cases than just the 1 I've run into I
> could help make a more productive assessment.
>
> RTG
>
>
>
> On 3/8/2010 12:00 PM, Joey Parrish wrote:
> > On Mar 8, 2010, at 10:44 AM, Ariel Sommeria wrote:
> >
> >
> >> Hi all,
> >> We've been tossing the idea of plugins for AMFPHP around, and so here's
> what come of it. Please share your thoughts on this.
> >>
> >> Why?
> >> People who want to contribute to the AMFPHP community currently mst have
> their contribution vetted by me. Not only am I a poor judge, but I'm also
> lazy. So the idea is to provide a system where someone who has a cool idea
> can push it to the community and let the community decide.
> >>
> >> Design Goals
> >> Flexibilty, extensibilty, simplicity, convention over configuration
> >>
> >> How (global design)?
> >> I've looked around a bit, and what seems to work elsewhere and that I
> quite like is a system of hooks. The idea is that at certain points in the
> execution of the script the possibility is given to the plugins to interact
> with the data flow. Here's a simple example: Your plugin wants to add a
> service to those available in the usual "services " folder. When the gateway
> tries to direct a service call, instead of just routing it to the services
> folder, it can ask the plugins first if they have a matching service.
> >>
> >> How (technical specifics)?
> >> There will be a new "plugins" folder in amfphp. Each plugin will consist
> at the very least of a subfolder and an index.php. When called this
> index.php will register for all needed hooks. To continue with the example,
> the index.php will register a function "addMyService" for the hook
> "LIST_SERVICES". When LIST_SERVICES is called by the gateway, the plugin's
> "addMyService" function will be called, and it will return the path to the
> plugin's service.
> >>
> >>
> > I suggest tweaking this structure a bit.
> > A plugin called xyz could consist of:
> >
> > plugins/xyz.php
> > plugins/xyz/   (optional)
> >
> > plugins/xyz.php would contain a class called xyz which implements a hook
> registration method.  The plugin could have all of it's code in the class
> xyz, or it could host a variety of other things in the xyz folder if the
> plugin is complex/organized enough to warrant it.
> >
> > The advantage of a structured class over registering functions in
> index.php:
> >
> > 1) Because the registration lives in a class method, someone can't just
> point their browser at a php file and see the registration functions failing
> left and right.
> > 2) For simple plugins, a folder is not needed.  The plugin can be
> self-contained in one file.  I like that a simple plugin could be compact.
> > 3) You still have a folder convention for more complex plugins to keep
> resources in.  This could be swfs, graphics, more php classes, whatever.
> > 4) If plugins are object-oriented, each plugin's hooks have their own
> namespace.  plugin2::filter() doesn't conflict with plugin5::filter().
> >
> > What do you think about this structure?
> > --Joey
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > amfphp-cvs mailing list
> > amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
> >
> >
> >
> >
> > E-mail message checked by Spyware Doctor (7.0.0.514)
> > Database version: 6.14510
> > http://www.pctools.com/en/spyware-doctor-antivirus/
> >
> >
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>

I'm in agreement with Joey on this one, class structure is much cleaner.

I would like to know more about what a plug-in would do, like a use case 
where:

1. A service is called, passing in data from the client
2. The plug-in executes
3. The data, (effected by the plug-in???), returns

If I knew more 'real world' use cases than just the 1 I've run into I 
could help make a more productive assessment.

RTG



On 3/8/2010 12:00 PM, Joey Parrish wrote:
> On Mar 8, 2010, at 10:44 AM, Ariel Sommeria wrote:
>
>    
>> Hi all,
>> We've been tossing the idea of plugins for AMFPHP around, and so here's what come of it. Please share your thoughts on this.
>>
>> Why?
>> People who want to contribute to the AMFPHP community currently mst have their contribution vetted by me. Not only am I a poor judge, but I'm also lazy. So the idea is to provide a system where someone who has a cool idea can push it to the community and let the community decide.
>>
>> Design Goals
>> Flexibilty, extensibilty, simplicity, convention over configuration
>>
>> How (global design)?
>> I've looked around a bit, and what seems to work elsewhere and that I quite like is a system of hooks. The idea is that at certain points in the execution of the script the possibility is given to the plugins to interact with the data flow. Here's a simple example: Your plugin wants to add a service to those available in the usual "services " folder. When the gateway tries to direct a service call, instead of just routing it to the services folder, it can ask the plugins first if they have a matching service.
>>
>> How (technical specifics)?
>> There will be a new "plugins" folder in amfphp. Each plugin will consist at the very least of a subfolder and an index.php. When called this index.php will register for all needed hooks. To continue with the example, the index.php will register a function "addMyService" for the hook "LIST_SERVICES". When LIST_SERVICES is called by the gateway, the plugin's "addMyService" function will be called, and it will return the path to the plugin's service.
>>
>>      
> I suggest tweaking this structure a bit.
> A plugin called xyz could consist of:
>
> plugins/xyz.php
> plugins/xyz/   (optional)
>
> plugins/xyz.php would contain a class called xyz which implements a hook registration method.  The plugin could have all of it's code in the class xyz, or it could host a variety of other things in the xyz folder if the plugin is complex/organized enough to warrant it.
>
> The advantage of a structured class over registering functions in index.php:
>
> 1) Because the registration lives in a class method, someone can't just point their browser at a php file and see the registration functions failing left and right.
> 2) For simple plugins, a folder is not needed.  The plugin can be self-contained in one file.  I like that a simple plugin could be compact.
> 3) You still have a folder convention for more complex plugins to keep resources in.  This could be swfs, graphics, more php classes, whatever.
> 4) If plugins are object-oriented, each plugin's hooks have their own namespace.  plugin2::filter() doesn't conflict with plugin5::filter().
>
> What do you think about this structure?
> --Joey
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>
>
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14510
> http://www.pctools.com/en/spyware-doctor-antivirus/
>
>    

On Mar 8, 2010, at 10:44 AM, Ariel Sommeria wrote:

> Hi all, 
> We've been tossing the idea of plugins for AMFPHP around, and so here's what come of it. Please share your thoughts on this. 
> 
> Why?
> People who want to contribute to the AMFPHP community currently mst have their contribution vetted by me. Not only am I a poor judge, but I'm also lazy. So the idea is to provide a system where someone who has a cool idea can push it to the community and let the community decide.
> 
> Design Goals
> Flexibilty, extensibilty, simplicity, convention over configuration
> 
> How (global design)?
> I've looked around a bit, and what seems to work elsewhere and that I quite like is a system of hooks. The idea is that at certain points in the execution of the script the possibility is given to the plugins to interact with the data flow. Here's a simple example: Your plugin wants to add a service to those available in the usual "services " folder. When the gateway tries to direct a service call, instead of just routing it to the services folder, it can ask the plugins first if they have a matching service. 
> 
> How (technical specifics)?
> There will be a new "plugins" folder in amfphp. Each plugin will consist at the very least of a subfolder and an index.php. When called this index.php will register for all needed hooks. To continue with the example, the index.php will register a function "addMyService" for the hook "LIST_SERVICES". When LIST_SERVICES is called by the gateway, the plugin's "addMyService" function will be called, and it will return the path to the plugin's service.
> 

I suggest tweaking this structure a bit.
A plugin called xyz could consist of:

plugins/xyz.php
plugins/xyz/   (optional)

plugins/xyz.php would contain a class called xyz which implements a hook registration method.  The plugin could have all of it's code in the class xyz, or it could host a variety of other things in the xyz folder if the plugin is complex/organized enough to warrant it.

The advantage of a structured class over registering functions in index.php:

1) Because the registration lives in a class method, someone can't just point their browser at a php file and see the registration functions failing left and right.
2) For simple plugins, a folder is not needed.  The plugin can be self-contained in one file.  I like that a simple plugin could be compact.
3) You still have a folder convention for more complex plugins to keep resources in.  This could be swfs, graphics, more php classes, whatever.
4) If plugins are object-oriented, each plugin's hooks have their own namespace.  plugin2::filter() doesn't conflict with plugin5::filter().

What do you think about this structure?
--Joey

Hi all,
We've been tossing the idea of plugins for AMFPHP around, and so here's what
come of it. Please share your thoughts on this.

Why?
People who want to contribute to the AMFPHP community currently mst have
their contribution vetted by me. Not only am I a poor judge, but I'm also
lazy. So the idea is to provide a system where someone who has a cool idea
can push it to the community and let the community decide.

Design Goals
Flexibilty, extensibilty, simplicity, convention over configuration

How (global design)?
I've looked around a bit, and what seems to work elsewhere and that I quite
like is a system of hooks. The idea is that at certain points in the
execution of the script the possibility is given to the plugins to interact
with the data flow. Here's a simple example: Your plugin wants to add a
service to those available in the usual "services " folder. When the gateway
tries to direct a service call, instead of just routing it to the services
folder, it can ask the plugins first if they have a matching service.

How (technical specifics)?
There will be a new "plugins" folder in amfphp. Each plugin will consist at
the very least of a subfolder and an index.php. When called this index.php
will register for all needed hooks. To continue with the example, the
index.php will register a function "addMyService" for the hook
"LIST_SERVICES". When LIST_SERVICES is called by the gateway, the plugin's
"addMyService" function will be called, and it will return the path to the
plugin's service.

What about plugins for the service browser?
 The plugin registers for the hook GET_SERVICE_BROWSER_PLUGINS, and
naturally takes the opportunity to add a nearby SWF.

That's all for now. I know it's a bit sketchy, but once we get the basics
down I'll flesh this out.
Ariel

Works for me


On 2/24/2010 8:48 AM, Ariel Sommeria wrote:
> Hi everyone,
> I'm reviving the developer mailing list. Is anyone still interested in 
> discussing future developments here?
> Ariel
>
>
>
> *
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14430
> http://www.pctools.com/spyware-doctor-antivirus/ 
> <http://www.pctools.com/en/spyware-doctor-antivirus/>
> *
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14430
> http://www.pctools.com/en/spyware-doctor-antivirus/
>    
>
>
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>
>
>
>
> E-mail message checked by Spyware Doctor (7.0.0.514)
> Database version: 6.14430
> http://www.pctools.com/en/spyware-doctor-antivirus/
>    

Hi everyone,
I'm reviving the developer mailing list. Is anyone still interested in
discussing future developments here?
Ariel

I have amf 1.9 and I'm notificing that serialization can be really slow at
times. It can take upwards of 1 second to serialize some of the requests I'm
making. The amount of data isn't huge either, under 100K serialized.

Since these requests are repeated often, my thought is to cache the
serialized amf output. Has anyone tried doing this?

 <amf...@li...>Hi List,

I am developing an online game which usages AMFPHP to save and read data
from a mysql database. The application seems to fail to connect with the
mysql database, (all the other functionality is behaving in the right manner
- even objects in related classes to the service class).

here is my connect function

function connect( $dns ) {

$h = $dns[ 'hostspec' ] ;
$u = $dns[ 'username' ] ;
$p = $dns[ 'password' ] ;

$this->db = @mysql_connect( $h, $u, $p );
@mysql_select_db( $dns[ 'database' ] );

if ( !$this->db ) {
die( 'MySQL Error: ' . mysql_error() );
} else {
$this->db_name = $dns[ 'database' ];
$this->connected = true;
}

and the return error is:
(Object)#0
message = "faultCode:INVALID_AMF_MESSAGE faultString:'Invalid AMF message'
faultDetail:''"
name = "Error"
rootCause = (null)


any idea what could be the issue?
would pay for anyone who is capable of solving this issue.

Thanks in advance,
Alon