On Feb 16, 2008, at 2:42 PM, Kevin Brown wrote:
Really, we're not as big of amateurs as some of this code might lead
you to
believe ;-).
No worries that is quite apparent to anyone with some experience and i
had made no such assumptions :-)
We already have a PHP sub-directory, and some other people were
actively
working on this. You might want to check the mail archives to see
who's
doing what, as I've kind of forgotten myself.
I haven't seen anyone working on the php code base in the svn
repository, and while i did occasionally see a 'i want to make a php
version', i've seen little in the form up status updates, code or
anything else, which made me a bit afraid that right now this effort
might be in the conceptual stage and not yet quiet in the actual
realization faze, also Cassie's call for people to help update the PHP
code base to use the new features javascripts instead of the old (0.2
or 03?) javascripts which were used to make the php prototype, were as
far as i am aware, unanswered except by someone who said "explain to
me how everything works in non document type language but in pseudo
code and i'll make it", also not something that gave me a lot of
confidence that this process is now well under way (no offense meant
btw to that person). (I did respond offlist to Cassie to notify of my
ongoing porting project, so maybe those other people is me?)
If anyone else -is- working on the same, i would love to hear from you
of course so we can perhaps combine our efforts.
So presuming i am currently the only one working on a php port of
shindig (thats looking to contribute it to the shindig project), what
would be the procedure to submit my code for inspection and inclusion?
Also, have you investigated using the Java implementation and simply
talking
to it from your PHP code base using the RpcServlet? A few other
people have
had success with this approach and it might get you what you're
looking for.
Yep, we've privately exchanged emails on this a few days ago, while
this is a great solution in many situations, the company i currently
work for doesn't want to add another software stack to his 400+
servers, nor do they feel confident that their resident programmers
could handle any problems that might arise when something would need
to be fixed, in the java code, and with over a few hundred thousands
of vocal, paying customers who have our customer support numbers,
thats something they would rather not risk.
So for me (and i' m sure for more people in the future in similar
situations) having a good and proper php code base to work with is
much preferred over either using gmodules.com in any way shape or form
(since adding an external dependency is a business risk too, even if
it's google :-)), nor is using another software stack since the in-
house knowledge is lacking to support this.
Besides most of the hard parts are already done, the gadget spec
parsing, translating and feature support, all i need to finish now is
the caching, proxy, rpc and security token bits and their a lot easier
to make since it involves a lot less reverse engineering of partially
undocumented specs from java code (though as we discussed off list,
Caja is still the big unknown factor in this until there's something
like command line version available)
-- Chris
