I think some people do actually do it, but honestly, what we've seen so
far is that if the core team doesn't write it it doesn't get written by
anyone. There are some exceptions but that seems to be a general case.
In this case, I do believe we've settled upon resolutions for all the
issues we felt were important (Tom outlined some of them) and probably
will produce a database backed implementation after 2.0 is released. To
date I don't think we have any plans to bundle it with the base release
because we don't really want any functionality we ship in that release
to require a database (or any other external system of that magnitude).
Jon Warbrick wrote:
> On Thu, 7 Jun 2007, Michael White wrote:
>
>> I am, though, also interested in the idea of investigating the database
>> approach for eduPersonTargetedID (we're still very early in our
>> implementation, so plenty of time to change tack!) - is there anyone out
>> there already doing this who would be willing to share what you've done
>> (code, DB schemas, resolver configuration etc would be nice :-) ) to
>> give the rest of us a leg-up?
>
> I asked about this a while ago on the shibboleth-users mailing list. The
> _only_ reply (apart from one 'Me too...') was a reference to this
> document by Jim Fox at the University of Washington:
>
> http://staff.washington.edu/fox/notes/tgtid.shtml
>
> It's slightly odd - there seems to be widespread agreement that storing
> eduPersonTargetedID values in a database is a good idea, but either
> almost no one is doing it or they are but are unwilling to share what
> they have done.
>
> Jon.
>
--
Chad La Joie 2052-C Harris Bldg
OIS-Middleware 202.687.0124
|