Shibboleth Developers

["Scott Cantor" <>]

> I'm a bit rusty here. What I'll do is subclass SSCache and redefine the
> methods I need to use one storage service or another.

You could, but I was mainly suggesting as an interim step you could just copy 
the existing code, make the changes, and override the existing factory 
registration to use your version for this plugin type. I meant subclass 
abstractly, not in the C++ sense.

It isn't really designed to be subclassed, there's no header file and it's 
not a public API.

The changes are basically to add additional StorageService members to use for 
the other storage operations, and some config attributes to reference the 
StorageService plugin to use at runtime to populate those members. (It's what 
Spring does in Java, basically.)

That said, if you can manage to subclass it, that's obviously nicer to 
maintain. But I didn't design the classes all that coherently inside that 
source file, I usually take shortcuts inside my C++ when it's not API code.

> I know how to do this as an extension, like I did with the memcache
> storage service, but where in the config file do I specify which class
> to use as SessionCache?

You can't, C++ doesn't have reflection. You have to register a factory 
function that manufactures the right class and register it against a type 
name. The name is just a string, and each class of plugin has its own map of 
strings to functions.

You can think of the type name as a class name, but you have to bind it to a 
C++ class at runtime by registering it in a map, it can't be done via a 
config file.

(I'm going to document all this, but it hasn't come up in the past, so it's 
low priority.)

> I just override the STORAGESERVICE_SESSION_CACHE ("StorageService") factory?

That's what I'm suggesting. You certainly don't have to...you can make up 
your own (preferably domain-qualified) type name and register it, either way 
is fine.

> "StorageService" seems a strange name for
> the factory that generates the session cache implementation.

Type names are specific to a type of plugin. "StorageService" only applies as 
a type of SessionCache. There's no reason to put "SessionCache" on the end of 
the type names, it just makes them longer for no reason.

> Just to be sure, all the caches I have to share among a cluster of SPs
> are:
> - SessionCache
> - ReplayCache
> - ArtifactMap
> 
> Right?

I think so, but in the context of this plugin it doesn't really matter. If 
you implement the API, anything that depends on them works. I can't and won't 
promise you what will use the API in the future.

> PS- Attached I send the first version of the Memcache Storage Service
> plugin. It depends on libmemcached
> (http://tangent.org/552/libmemcached.html) and boost
> (http://www.boost.org/).

If you have any way to avoid using boost, I would do it. Boost is not 
packaged in a manner that makes it feasible to install easily for people that 
do source builds. It's easy on Windows, and Linux has RPMs, but a source 
build requires the JAM make tool. They've been asked to use autoconf, but 
their response is that "this is not intended to be used in software that has 
to be distributed as source and built". It's basically like a testbed for C++ 
features that might show up in the future STL. As a library to build on, it's 
not the best setup.

That said, it's really your call. I don't expect to push the memcache SS 
itself into the shibsp code, only the patch to make the session cache plugin 
able to leverage multiple SS plugins for different contexts.

> To configure it:
> 
> 
>     <StorageService type="MEMCACHE" id="mc" prefix="KEY_PREFIX:">

You want to make your type like a Java package for uniqueness. Only the core 
team get to use short names. ;-)

-- Scott