[p2pu-dev] [jsFiddle] Zalun - Thanks for your comment re /show/
Dan Diebolt
dandiebolt at gmail.com
Wed Apr 13 19:34:37 UTC 2011
Down the road I could see P2PU users entering their git, jfiddle or other
public identifiers into their profile similar to how some platforms ask for
instant messaging handles, twitter ids etc. If these identity associations
were syndicated out or exposed via an API for a particular course there
might be a way to associate between P2PU identity and external content. Here
is a crude mapping manually maintained in the fiddle that would link the
owner of the jsFiddle back to the P2PU handle / contact form:
http://jsfiddle.net/dandiebolt/e5P6a/embedded/result,html,css,js/
<http://jsfiddle.net/dandiebolt/e5P6a/embedded/result,html,css,js/>I would
have to think about the implications of this further. Having this info
exposed publicly without a login and in the aggregate is a concern. But it
is no different than the current practice of throwing up a public
spreadsheet for all the world to see if they know the URL or hanging the
same info off a public web site in unaggregated but scrapable form.
The more I think about it the more I think you need authentication and
tighter integration. This is another area where the total transparency
thinking breaks down.
On Wed, Apr 13, 2011 at 2:34 PM, Piotr Zalewa <piotr at zalewa.info> wrote:
> If it's always the case that a user needs to be logged in to jsFiddle
> then the first parameter of a fiddle is the username.
>
> http://jsfiddle.net/{username}/{fiddle_id}/
>
> zalun
>
> On 04/13/11 18:55, Dan Diebolt wrote:
> >>Wouldn't providing a JSONP by server with the jsFiddle's
> > get_username solve this issue?
> >
> > I think what we would want out of your API is the owner of the fiddle
> > (any any other meta data you could spit out) not the jsfiddle user
> > currently logged in.
> >
> > Actually that is a practical suggestion which would inch us closer to
> > something workable. I am only looking for a workaround as the problem is
> > that when jsFiddles are used by a large course it quickly becomes a big
> > problem managing hundreds of jsFiddles and associating them with a
> > specific P2PU user identity. The problem is more on the P2PU side as the
> > same problem occurs with any URL that might represent an assignment or
> > course work product (blog URL, video URL etc).
> >
> > My thinking was focusing on information flowing programmatically from
> > the host page to the embedded fiddle as it was the P2PU user name that
> > was needed within the jsfiddle.
> >
> > However, for this use case we can probably make it work getting the user
> > name from jsfiddle using your JSONP API and doing a reverse lookup so to
> > speak to get the P2PU user name.*Is there an existing API that would
> > return the fiddles associated with particular user or tagged in some
> way?*
> >
> > This would involve manually maintaining a mapping (perhaps in javascript
> > and included in the fiddle as a resource) between the P2PU user name to
> > the jsFiddle externally but course organizers have to do that manually
> > already if they maintain any type of roster or assignment.
> >
> > {"zalun": "zalun",
> > "sproket": "dandiebolt"}
> >
> > Piotr (idempotent!)
> > http://jsfiddle.net/user/zalun/ <=> http://p2pu.org/users/zalun
> >
> > Dan
> > http://jsfiddle.net/user/dandiebolt/ <=>
> http://www.p2pu.org/users/sproket
> >
> >
> >
> > On Wed, Apr 13, 2011 at 1:26 PM, Piotr Zalewa <zaloon at gmail.com
> > <mailto:zaloon at gmail.com>> wrote:
> >
> > Wouldn't providing a JSONP by server with the jsFiddle's get_username
> > solve this issue?
> >
> > On 04/13/11 17:10, Dan Diebolt wrote:
> > > @Zuzel: I am not suggesting the passing of the actual credentials,
> > > cookies, session ids or security nonce. What I want to achieve is
> some
> > > way to parameterize the embedded content based on some state of
> > the host
> > > page for two basic reasons:
> > >
> > > *First Reason: Convenient Management of Course Roster, Assignments
> &
> > > Course Resources*
> > >
> > > Let me give you a real example: many course organizers maintain a
> > > off-line spreadsheet for their class privately or perhaps share a
> > > spreadsheet / database for viewing or even editing by the course
> > > participants. Here are a variety of examples representing
> information
> > > such as a class roster, assignment urls, assignment completions and
> > > other info:
> > >
> > > *Wordpress Development Course*
> > >
> >
> https://spreadsheets.google.com/pub?key=0AtIU11tP1lgFdFhwU2lqXzVoaUtueVl5TWdsTGkwVGc&hl=en&output=html
> > <
> https://spreadsheets.google.com/pub?key=0AtIU11tP1lgFdFhwU2lqXzVoaUtueVl5TWdsTGkwVGc&hl=en&output=html
> >
> > >
> > <
> https://spreadsheets.google.com/pub?key=0AtIU11tP1lgFdFhwU2lqXzVoaUtueVl5TWdsTGkwVGc&hl=en&output=html
> > <
> https://spreadsheets.google.com/pub?key=0AtIU11tP1lgFdFhwU2lqXzVoaUtueVl5TWdsTGkwVGc&hl=en&output=html
> >>
> > >
> > > *School of WebCraft jQuery Course Group 1 Roster*
> > >
> >
> https://www.quickbase.com/db/bfx7sqpm8?a=dbpage&pagename=jQueryGroup1.html
> > <
> https://www.quickbase.com/db/bfx7sqpm8?a=dbpage&pagename=jQueryGroup1.html
> >
> > >
> > <
> https://www.quickbase.com/db/bfx7sqpm8?a=dbpage&pagename=jQueryGroup1.html
> > <
> https://www.quickbase.com/db/bfx7sqpm8?a=dbpage&pagename=jQueryGroup1.html
> >>
> > >
> > > *Edit Grid (Live Editable Spreadsheet)*
> > > http://p2pu.org/webcraft/node/27443/document/28447
> > >
> > > *Google Charts (Form & Report)*
> > > http://p2pu.org/webcraft/node/27443/document/27520
> > >
> > > Without passing any information from the host to
> > > the embedded spreadsheet / database you cannot distinguish one
> > user from
> > > another so the embedded content is made view only or if made
> editable
> > > subject to being overwritten by accident or otherwise. Yes it is
> > > security by obscurity no matter how you slice it but large courses
> > can't
> > > wait a year for a specific feature to be implemented in the
> > > P2PU platform and there will always be innovative ways to bring new
> > > content into a P2PU course which might benefit from a way to pass
> some
> > > type of parameter such as the user name, course name, section name,
> > > school name, task name, url resource etc. Nobody is every going to
> be
> > > able to build all the requisite content sharing features into the
> P2PU
> > > platform as fast as user will come up with new content innovations
> so
> > > some type of generic content embedding and simple parameter passing
> is
> > > needed. Courses can't wait for generic embed mechanisms such as
> > > oembed.com <http://oembed.com> <http://oembed.com>, embed.ly
> > <http://embed.ly> <http://embed.ly> to mature and
> > > settle out.
> > >
> > > *Second Reason: Conveniently Build Course Examples & Helper
> Utilities
> > > Without Consuming and Waiting for Development *
> > > *
> > > *
> > > The ability to pass some type of parameter from the host page
> > > to embedded content will allow one miniature external resource to
> be
> > > re-used for a variety of purposes.
> > >
> > >
> > >
> > > _______________________________________________
> > > p2pu-dev mailing list
> > > p2pu-dev at lists.p2pu.org <mailto:p2pu-dev at lists.p2pu.org>
> > > http://lists.p2pu.org/mailman/listinfo/p2pu-dev
> >
> >
> > --
> > blog http://piotr.zalewa.info
> > fidd http://jsfiddle.net/user/zalun/
> > twit http://twitter.com/zalun
> > face http://facebook.com/zaloon
> >
> >
>
>
> --
> blog http://piotr.zalewa.info
> fidd http://jsfiddle.net/user/zalun/
> twit http://twitter.com/zalun
> face http://facebook.com/zaloon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-dev/attachments/20110413/fd7bafea/attachment-0001.html>
More information about the p2pu-dev
mailing list