Bright Content developer's meeting, 2008-02-28
Attending: Uche Ogbuji, Eric Larson, Eric Miller
Primary topic of discussion today is BC Roadmap
UO: I suggest we create a single roadmap page for all xml3k projects. See draft at http://notes.4suite.org/Roadmap
EL: I'm wondering if projects should have separate roadmaps
UO: I'm Ok with that, but there will be a lot of intertwining. e.g. Amara depends on 4Suite, BC depends on Amara, AmpLee and xsltemplates and WSGI.xml. The latter 2 will be merging
EL: I'm wondering if xml3k looks like a huge project it is good b/c it looks big, but it also might make getting contributors on board difficult...essentially seeing too much todo, etc. with that said, if it isn't an issue at the moment (arguably it isn't) then one is great with me. most of the projects are somewhat "merging" so one large roadmap works for me
UO: xml3k is not one mega-project. We should clarify that on the Wiki. there is plenty of precedent for such copmposite projects e.g. PEAK, Py, etc.
My guess is that xml3k will merge into about 5 projects
- Amara (which will absorb 4Suite)
- WSGI.xml (which will absorb xsltemplate)
- Bright Content
- rdflib (which will absorb 4RDF)
- the server component of 4Suite we'll be updating/finalizing up for CCF. Proposed names: Uli Web, Akara...
UO: OK, so the next step we had before was 4Suite and Amara 2.0. Jeremy put us back on the path to accomplish that yesterday. I think we can have a beta of 4Suite 2.0 out in March, and Amara 2.0 in April. I'd say we keep BC 0.5 dependent on only current versions. i.e. 4Suite 1.0.3 and Amara 1.2. Actually 4Suite 1.0.3 is not released, and needs to be. That should be the first Roadmap item, scheduled for next week
EM: +1 to BC dependency to current versions
UO: Can we say BC 0.5 by end of next week? which really means by Weds, because I'm traveling. I'd guess it's all just further testing and clean-up. And I'd like to incorporate the OpenID client for 0.5 Does that seem feasible?
EL: 0.5 seems reasonable by next week. I'd like to wrap up code commenting and get documentation up for the Store -> StoreManager patttern. that is semi-official at this point.
UO: So here is what I have so far... http://wiki.xml3k.org/Roadmap . I put down 12 March for BC 0.5 . We can still shoot for Weds
EL: I do agree BC should always use released bits ie 4suite, xsltemplates, amplee, etc
UO: which means we should release a new xsltemplates the released (ie cheeseshop) amplee works which is good
and do the WSGI.xml migration for 0.6? When do you think you can package/release xsltemplates
EL: I can push what I have today. then we should go ahead and merge into wsgi.xml
UO: I'll just put down March 5. I put down March 10 for merge. what version xsltemplate will that be?
EL: 0.5
UO: We also need an AmpLee release. we can go off of the cheeseshop release now. Could you ask Sylvain?
EL: it is already in the bc setup.py to use amplee > 0.5
UO: I thought we needed amplee SVN
EL: not anymore. he did a release the other day
UO: I'll update my install notes
UO: Well, I think Roadmap is cooked enough
After the meeting there was some relevant follow-up discussion:
EL: I like Akara for the VFS-y generic XML/RDF store
UO: I think Chime likes Uli Web
EL: your akara stuff seemed to always come up in google and since it seems like a natural progression
EL: the down side with Uli is I always have to look really closely to see how it is spelled... there I said it
EM: +1 for akara (note: i suck at naming... standard disclaimers apply)
UO: OK all. I updated sample instructions: http://wiki.xml3k.org/Bright_Content/Sample_setups
UO: EricL, finally getting out meeting notes. Were you OK with including OpenIDClient in the roadmap? And if so as a separate component? Or packagesd in BC? (wonders whether it could go in WSGI.xml, though it's not technicaly XML)
EL: I'd say put openid in Bright Content
UO: OK, can we do that for 0.5?
EL recommended putting the OpenID client component into BC core, and thinks we can do so for the 0.5 release
EL: it is like a service, and not like a library. I say that b/c it is not like authkit for example that provides a decorator
UO: that does sorta make sense but wouldn't that mean a user has to hack code to enable openid for particular components?
EL: not necessarily. the component can say is "authentication" on and check for bc.authenticated.user in the environ.This is not how it works now but could.Then the openid runs as a service and adds the authenticated bits to the environ.I suppose you could register an authentication scheme in the config.like authentication.my_plugin = bc#openid
EL: That would uses the openid entrypoint in BC and provides an URL in the environ.something like:
if not environ['bc.authenticated.user']: return HTTPSeeOther(location=environ['bc.authentication.service'])
UO: I like that even better