[Catalyst] Squatting::On::Catalyst

Ash Berlin ash_cpan at firemirror.com
Wed Jul 30 12:02:08 BST 2008


On 30 Jul 2008, at 02:27, John Beppu wrote:

>
>
> On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty <danielmcbrearty at gmail.com 
> > wrote:
> my 0.05 (possibly a bit OT) :
>
> Off-topic or not, I think these are interesting and valid questions.
>
> I looked previously at a few ways of adding forums etc to the site
> using 3rd party code, indeed there are many possibilites (some perl,
> some not)
>
> The thing that was always a sticker for me was getting some kind of
> logical integration, ie:
>
> 1. letting users keep existing member and login creds
>
> Now that composition and embedding of web apps is becoming a  
> reality, we have to start anticipating needs like this.  For  
> example, the documentation for an app that's built to be embedded  
> could state that:
> It expects a user object to be in its session's "u" key.
> The app will expect to be able to call the ->name method on this  
> user object.  (Some apps may want more...  others less...  this is  
> just a hypothetical example.)
> If that key is undef, the app will assume the current session is not  
> in a "logged in" state.
>  I think being up-front about login policy would be enough to share  
> users across multiple web apps joined together as one cohesive unit.


I dont. Lets take the example of embedding a forum. It will most  
likely store its data in a DB of its own design. It will also quite  
likely have its own user table, and have FKs referencing that  
table.... see the problem? There's more to sharing users than just  
logging.

I can't really see any way around that other than on a case-by-case  
basis sadly. Someone please feel free to correct me.

-ash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080730/dcba49e1/attachment.htm


More information about the Catalyst mailing list