[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