[p2pu-dev] [jsFiddle] Zalun - Thanks for your comment re /show/

[Dan Diebolt]

>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> 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
> >
> >
> > *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
> >
> >
> > *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>, 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-dev/attachments/20110413/5f9b5cdb/attachment.html>