Re: [amfphp-cvs] plugins in amfphp

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
>
>