You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Rajdeep Dua <ra...@google.com> on 2008/06/25 18:44:57 UTC
Shindig PHP Architecural Overview Article
Hi Alll,
I have written an Article on Shindig PHP Architecture, available at the
following location
http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html
Kindly provide feedback and if it can be linked from the Apache site
Thanks
Rajdeep
RE: Schema sources (was Re: Shindig PHP Architecural Overview Article)
Posted by "Michael Ryan (Software Developer)" <Mi...@apollogrp.edu>.
Without cluttering the js/API itself, not so much, JavaScript itself
doesn't have an internal enumeration type, usually this is worked around
by having a static class that has each key to a paired value that is
used, this makes the code more obvious as you can use friendly
inferences maybe through an enum helper...
if (Enum.contains(enumeration, value)) ...
would be easier against multiple enumerations as opposed to creating
static case statements...
I don't know all the specifics of the JS for shindig, just javascript in
general.
--
Michael J. Ryan -- Software Developer -- Apollo Group
> -----Original Message-----
> From: Dan Brickley [mailto:danbri@danbri.org]
> Sent: Thursday, June 26, 2008 3:50 AM
> To: shindig-dev@incubator.apache.org
> Subject: Re: Schema sources (was Re: Shindig PHP Architecural Overview
> Article)
>
> Dan Brickley wrote:
> > Rajdeep Dua wrote:
> >> Thanks for the encouraging feedback.
> >> Chris - I will make the changes based on your feedback
> >>
> >> The schema diagram has been drawn manually -- no auto-generation
as
> >> of now
> >> ,exploring various tools to do this.
> >
> > Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the
> > most authoritative source spec for the schema? I'm looking at
mapping
> > this stuff into RDF/FOAF, but for now have just worked from one of
> the
> > demo SQL backends that was circulated...
>
> Kevin Marks in IRC gently encouraged me to look in the spec,
>
> phenny: danbri: 07:27Z <KevinMarks> tell danbri OpenSocial Person
field
> is in the Spec:
>
http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.P
> erson.Field
>
> Which apart from making me realise it was a dumb sounding question,
> makes me also clarify my question: is there a *machine-friendly*
schema
> of some kind that can be used as a common authoritative source. The
> spec
> source doesn't seem designed (microformats-style) to be
machine-parsed.
>
> To which Kevin in IRC is just now replying: these docs are generated
by
> javadoc from the Javascript API source. And a copy of that seems to be
> in the Apache SVN:
>
>
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/openso
> cial-reference/person.js
> ...and more in
>
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/openso
> cial-reference/
>
>
> So I'll treat that as authoritative at least until I find a copy on
the
> main opensocial site...
>
>
> Looking there in person.js I see (to use gender as an example)
>
> /**
> * Person's gender, specified as an opensocial.Enum with the enum's
> * key referencing opensocial.Enum.Gender.
> * Container support for this field is OPTIONAL.
> *
> * @member opensocial.Person.Field
> */
> GENDER : 'gender',
>
> ...but nothing more in the js to associate either 'GENDER' or 'gender'
> with the enumerated values (rather than, say, a string). All the
typing
> information is in the comments.
>
> Over in enum.js we see the enumerated values, but I don't see how to
> programmatically associate them with the GENDER field:
>
> /**
> * @static
> * @class
> * The enum keys used by the gender field.
> * <p><b>See also:</b>
> * <a href="opensocial.Person.Field.html">
> * opensocial.Person.Field.Gender</a>
> * </p>
> *
> * @name opensocial.Enum.Gender
> */
> opensocial.Enum.Gender = {
> /** @member opensocial.Enum.Gender */
> MALE : 'MALE',
> /** @member opensocial.Enum.Gender */
> FEMALE : 'FEMALE'
> };
>
>
> Am I missing something obvious? Is there a way I can write a bit of
.js
> to determine that one field is string-valued, while another takes an
> enum?
>
> thanks for listening ;)
>
> cheers,
>
> Dan
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: Schema sources (was Re: Shindig PHP Architecural Overview Article)
Posted by Kevin Brown <et...@google.com>.
On Thu, Jun 26, 2008 at 3:49 AM, Dan Brickley <da...@danbri.org> wrote:
> Dan Brickley wrote:
>
>> Rajdeep Dua wrote:
>>
>>> Thanks for the encouraging feedback.
>>> Chris - I will make the changes based on your feedback
>>>
>>> The schema diagram has been drawn manually -- no auto-generation as of
>>> now
>>> ,exploring various tools to do this.
>>>
>>
>> Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the most
>> authoritative source spec for the schema? I'm looking at mapping this stuff
>> into RDF/FOAF, but for now have just worked from one of the demo SQL
>> backends that was circulated...
>>
>
> Kevin Marks in IRC gently encouraged me to look in the spec,
>
> phenny: danbri: 07:27Z <KevinMarks> tell danbri OpenSocial Person field is
> in the Spec:
> http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.Person.Field
>
> Which apart from making me realise it was a dumb sounding question, makes
> me also clarify my question: is there a *machine-friendly* schema of some
> kind that can be used as a common authoritative source. The spec source
> doesn't seem designed (microformats-style) to be machine-parsed.
>
> To which Kevin in IRC is just now replying: these docs are generated by
> javadoc from the Javascript API source. And a copy of that seems to be in
> the Apache SVN:
>
>
> http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/person.js
> ...and more in
> http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/
>
>
> So I'll treat that as authoritative at least until I find a copy on the
> main opensocial site...
The official versions used to generate the spec documentation are checked
into the opensocial-resources SVN repository on code.google.com:
http://opensocial-resources.googlecode.com/svn/spec/0.8/
>
>
> Looking there in person.js I see (to use gender as an example)
>
> /**
> * Person's gender, specified as an opensocial.Enum with the enum's
> * key referencing opensocial.Enum.Gender.
> * Container support for this field is OPTIONAL.
> *
> * @member opensocial.Person.Field
> */
> GENDER : 'gender',
>
> ...but nothing more in the js to associate either 'GENDER' or 'gender' with
> the enumerated values (rather than, say, a string). All the typing
> information is in the comments.
>
> Over in enum.js we see the enumerated values, but I don't see how to
> programmatically associate them with the GENDER field:
>
> /**
> * @static
> * @class
> * The enum keys used by the gender field.
> * <p><b>See also:</b>
> * <a href="opensocial.Person.Field.html">
> * opensocial.Person.Field.Gender</a>
> * </p>
> *
> * @name opensocial.Enum.Gender
> */
> opensocial.Enum.Gender = {
> /** @member opensocial.Enum.Gender */
> MALE : 'MALE',
> /** @member opensocial.Enum.Gender */
> FEMALE : 'FEMALE'
> };
>
>
> Am I missing something obvious? Is there a way I can write a bit of .js to
> determine that one field is string-valued, while another takes an enum?
>
> thanks for listening ;)
>
>
> cheers,
>
> Dan
>
> --
> http://danbri.org/
>
Re: Schema sources (was Re: Shindig PHP Architecural Overview Article)
Posted by Dan Brickley <da...@danbri.org>.
Dan Brickley wrote:
> Rajdeep Dua wrote:
>> Thanks for the encouraging feedback.
>> Chris - I will make the changes based on your feedback
>>
>> The schema diagram has been drawn manually -- no auto-generation as
>> of now
>> ,exploring various tools to do this.
>
> Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the
> most authoritative source spec for the schema? I'm looking at mapping
> this stuff into RDF/FOAF, but for now have just worked from one of the
> demo SQL backends that was circulated...
Kevin Marks in IRC gently encouraged me to look in the spec,
phenny: danbri: 07:27Z <KevinMarks> tell danbri OpenSocial Person field
is in the Spec:
http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.Person.Field
Which apart from making me realise it was a dumb sounding question,
makes me also clarify my question: is there a *machine-friendly* schema
of some kind that can be used as a common authoritative source. The spec
source doesn't seem designed (microformats-style) to be machine-parsed.
To which Kevin in IRC is just now replying: these docs are generated by
javadoc from the Javascript API source. And a copy of that seems to be
in the Apache SVN:
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/person.js
...and more in
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-reference/
So I'll treat that as authoritative at least until I find a copy on the
main opensocial site...
Looking there in person.js I see (to use gender as an example)
/**
* Person's gender, specified as an opensocial.Enum with the enum's
* key referencing opensocial.Enum.Gender.
* Container support for this field is OPTIONAL.
*
* @member opensocial.Person.Field
*/
GENDER : 'gender',
...but nothing more in the js to associate either 'GENDER' or 'gender'
with the enumerated values (rather than, say, a string). All the typing
information is in the comments.
Over in enum.js we see the enumerated values, but I don't see how to
programmatically associate them with the GENDER field:
/**
* @static
* @class
* The enum keys used by the gender field.
* <p><b>See also:</b>
* <a href="opensocial.Person.Field.html">
* opensocial.Person.Field.Gender</a>
* </p>
*
* @name opensocial.Enum.Gender
*/
opensocial.Enum.Gender = {
/** @member opensocial.Enum.Gender */
MALE : 'MALE',
/** @member opensocial.Enum.Gender */
FEMALE : 'FEMALE'
};
Am I missing something obvious? Is there a way I can write a bit of .js
to determine that one field is string-valued, while another takes an enum?
thanks for listening ;)
cheers,
Dan
--
http://danbri.org/
Schema sources (was Re: Shindig PHP Architecural Overview Article)
Posted by Dan Brickley <da...@danbri.org>.
Rajdeep Dua wrote:
> Thanks for the encouraging feedback.
> Chris - I will make the changes based on your feedback
>
> The schema diagram has been drawn manually -- no auto-generation as of now
> ,exploring various tools to do this.
Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the
most authoritative source spec for the schema? I'm looking at mapping
this stuff into RDF/FOAF, but for now have just worked from one of the
demo SQL backends that was circulated...
cheers,
Dan
--
http://danbri.org/
Re: Shindig PHP Architecural Overview Article
Posted by Rajdeep Dua <ra...@google.com>.
Thanks for the encouraging feedback.
Chris - I will make the changes based on your feedback
The schema diagram has been drawn manually -- no auto-generation as of now
,exploring various tools to do this.
Thanks
Rajdeep
On Wed, Jun 25, 2008 at 10:56 PM, Gonzalo Aune <go...@gmail.com>
wrote:
> Very helpful for new people =), great job!
>
> G.-
>
> On Wed, Jun 25, 2008 at 2:21 PM, Dan Brickley <da...@danbri.org> wrote:
>
> > Rajdeep Dua wrote:
> >
> >> Hi Alll,
> >> I have written an Article on Shindig PHP Architecture, available at the
> >> following location
> >>
> >> http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html
> >>
> >> Kindly provide feedback and if it can be linked from the Apache site
> >>
> >
> > Very handy :) Blogged at http://danbri.org/words/2008/06/25/347
> >
> > Re the schema/class diagram, ... what is this generated from? .js
> > somewhere? How do you keep it up to date?
> >
> > cheers,
> >
> > Dan
> >
> > --
> > http://danbri.org/
> >
>
Re: Shindig PHP Architecural Overview Article
Posted by Gonzalo Aune <go...@gmail.com>.
Very helpful for new people =), great job!
G.-
On Wed, Jun 25, 2008 at 2:21 PM, Dan Brickley <da...@danbri.org> wrote:
> Rajdeep Dua wrote:
>
>> Hi Alll,
>> I have written an Article on Shindig PHP Architecture, available at the
>> following location
>>
>> http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html
>>
>> Kindly provide feedback and if it can be linked from the Apache site
>>
>
> Very handy :) Blogged at http://danbri.org/words/2008/06/25/347
>
> Re the schema/class diagram, ... what is this generated from? .js
> somewhere? How do you keep it up to date?
>
> cheers,
>
> Dan
>
> --
> http://danbri.org/
>
Re: Shindig PHP Architecural Overview Article
Posted by Dan Brickley <da...@danbri.org>.
Rajdeep Dua wrote:
> Hi Alll,
> I have written an Article on Shindig PHP Architecture, available at the
> following location
>
> http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html
>
> Kindly provide feedback and if it can be linked from the Apache site
Very handy :) Blogged at http://danbri.org/words/2008/06/25/347
Re the schema/class diagram, ... what is this generated from? .js
somewhere? How do you keep it up to date?
cheers,
Dan
--
http://danbri.org/
Re: Shindig PHP Architecural Overview Article
Posted by Eiji Kitamura <ag...@gmail.com>.
Cool!!
Thank you very much for your great work!
2008/6/26 Rajdeep Dua <ra...@google.com>:
> Hi Alll,
> I have written an Article on Shindig PHP Architecture, available at the
> following location
>
> http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html
>
> Kindly provide feedback and if it can be linked from the Apache site
>
> Thanks
> Rajdeep
>
Re: Shindig PHP Architecural Overview Article
Posted by Chris Chabot <ch...@xs4all.nl>.
On Jun 26, 2008, at 11:38 AM, Kevin Brown wrote:
>
> Hmm -- ultimately though, won't this just wind up bundled in a tar
> ball or
> something? Perhaps we could have a simple "build" script for the PHP
> code
> that takes care of copying things to the right places. We could drop
> in a
> minification pass for the javascript while we're at it.
That is something i have considered before, especially when we were
talking about the javascript mimification (remember those threads,
month or 2 back).
However my big fear was, and still is really, that there will be a lot
of people who just want to 'ftp their files to their shared web
host'.. that audience probably has no idea about how bash works, let
alone more advanced stuff like build scripts and dependencies. I don't
even know if i can count on a command line/cli version of PHP being
available in general ... and if it is, if it's the same version as the
website (lots of bit messier web hosting companies have an upt-to-date
php & apache self-compiled, but standard distro php (v4.x).. *shudder*).
Really the amount of assumptions i can make about the platform is
incredibly limited, unless of course i make the choice to exclude all
but the more professional who have some basic system administration
background, my experience is though that that would exclude about 50%
of our potential audience on the php side (to give you an example:
setting up a basic shindig config is marked down as 'hard' already at
the code labs, because it involves making a vhost config in apache..)
So i'm extremely weary off and careful with adding any extra
'assumptions' to the requirements, and running a 'script' of any
kind ... well that adds a lot of assumptions already (tcsh? bash? sh?
which cli php version if any? windows, solaris, linux, bsd or? do they
even have shell access? many shared hosts do not). Scary territory to
thread into.
Thats the reason i went for on-the-fly compression of the javascript
files (though the results are cached, per feature so the performance
his is limited even on the first hit), it just by-passes a lot of
potential problems.
and on making a release tar ball, we simply change the default config
from <web root>/../javascript to <web root>/javascript .. or maybe
even leaving things as is since it's not so horrible not to have files
that shouldn't be served from apache outside of the web root anyhow.
-- Chris
Re: Shindig PHP Architecural Overview Article
Posted by Kevin Brown <et...@google.com>.
On Thu, Jun 26, 2008 at 2:25 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> maybe with an alias ..problem is that javascript (shindig/javascript) is
> living outside of the webroot (which is shindig/php), and i don't know for
> sure if .htaccess files allow to define such behavior.
>
> I'll go see, i agree that a htaccess rule is simpler then a bit of code :)
Hmm -- ultimately though, won't this just wind up bundled in a tar ball or
something? Perhaps we could have a simple "build" script for the PHP code
that takes care of copying things to the right places. We could drop in a
minification pass for the javascript while we're at it.
>
>
> On Jun 26, 2008, at 9:07 AM, Kevin Brown wrote:
>
>
>> I hadn't seen this one myself -- why is it even necessary? Couldn't this
>> just be a Directory or RewriteRule?
>>
>
>
Re: Shindig PHP Architecural Overview Article
Posted by Chris Chabot <ch...@xs4all.nl>.
maybe with an alias ..problem is that javascript (shindig/javascript)
is living outside of the webroot (which is shindig/php), and i don't
know for sure if .htaccess files allow to define such behavior.
I'll go see, i agree that a htaccess rule is simpler then a bit of
code :)
On Jun 26, 2008, at 9:07 AM, Kevin Brown wrote:
>
> I hadn't seen this one myself -- why is it even necessary? Couldn't
> this
> just be a Directory or RewriteRule?
Re: Shindig PHP Architecural Overview Article
Posted by Kevin Brown <et...@google.com>.
On Wed, Jun 25, 2008 at 10:16 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> Hey Rajdeep, this looks great!
>
> Only a few small bits of feedback that aren't really important but i'd
> still like to mention:
>
> # FilesServlet
> * Loads the HTML, JS, CSS files from the paths specified -- This servlet
> is unique to PHP Shindig Implementation.
>
> Actually this isn't from the 'path specified' but hard wires /gadgets/files
> to <shindig>/javascript. Java land also does this but then through jetty
> configuration. The purpose of it allow the examples
> (/gadgets/files/container/sample*.html and
> /gadgets/files/samplecontainer/samplecontainer.html) to work the same on
> both versions. I'm not saying your attribution is way off, however the
> wording would almost make one thing it's a huge security hole, while in fact
> is is not :-)
I hadn't seen this one myself -- why is it even necessary? Couldn't this
just be a Directory or RewriteRule?
>
>
> # Server Side Components diagram you list opensocial-0.7 depending on
> 'caja', this was actually removed a while ago, since it broke some gadgets
> and isn't completed yet. Nothing that would force an update of the graphics,
> it's not that important, but still a detail worth mentioning :)
>
> # pluggable classes. I'll leave it up to you to judge if this is relevant
> or not but a lot of the services can be re-configured to your own classes,
> things like the gadget blacklist, remote content fetcher & caching classes.
> The idea is that a lot of large sites will already have their own versions
> that they want to use, so we made all of those configurable (this is the
> same in Java land btw). But i guess that would make this document to
> complicated?
>
> Over all it looks great and it's very informative, thanks for your work!
>
> -- Chris
>
>
> On Jun 25, 2008, at 6:44 PM, Rajdeep Dua wrote:
>
> Hi Alll,
>> I have written an Article on Shindig PHP Architecture, available at the
>> following location
>>
>> http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html
>>
>> Kindly provide feedback and if it can be linked from the Apache site
>>
>> Thanks
>> Rajdeep
>>
>
>
Re: Shindig PHP Architecural Overview Article
Posted by Chris Chabot <ch...@xs4all.nl>.
Hey Rajdeep, this looks great!
Only a few small bits of feedback that aren't really important but i'd
still like to mention:
# FilesServlet
* Loads the HTML, JS, CSS files from the paths specified -- This
servlet is unique to PHP Shindig Implementation.
Actually this isn't from the 'path specified' but hard wires /gadgets/
files to <shindig>/javascript. Java land also does this but then
through jetty configuration. The purpose of it allow the examples (/
gadgets/files/container/sample*.html and /gadgets/files/
samplecontainer/samplecontainer.html) to work the same on both
versions. I'm not saying your attribution is way off, however the
wording would almost make one thing it's a huge security hole, while
in fact is is not :-)
# Server Side Components diagram you list opensocial-0.7 depending on
'caja', this was actually removed a while ago, since it broke some
gadgets and isn't completed yet. Nothing that would force an update of
the graphics, it's not that important, but still a detail worth
mentioning :)
# pluggable classes. I'll leave it up to you to judge if this is
relevant or not but a lot of the services can be re-configured to your
own classes, things like the gadget blacklist, remote content fetcher
& caching classes. The idea is that a lot of large sites will already
have their own versions that they want to use, so we made all of those
configurable (this is the same in Java land btw). But i guess that
would make this document to complicated?
Over all it looks great and it's very informative, thanks for your work!
-- Chris
On Jun 25, 2008, at 6:44 PM, Rajdeep Dua wrote:
> Hi Alll,
> I have written an Article on Shindig PHP Architecture, available at
> the
> following location
>
> http://rajdeep.dua.googlepages.com/shindigPHP-overview-tidy_img.html
>
> Kindly provide feedback and if it can be linked from the Apache site
>
> Thanks
> Rajdeep