Notes for Higgins dev call - Sep 23, 2010
Attendees . Mike McIntosh - Azigo . Paul Trevithick - Azigo . Mary Ruddy - Meristic . Alex - Azigo . Valery - Azigo Logistics . Time: Thursday 10:00 Eastern (16:00 UTC) U.S. . Skype: +9900827047990866 . Dial-in: 1-201-793-9022 passcode 7990866# Agenda 1. [Mary, Mike, John Bradley] 1.1 Open IPR list, status update, OpenID4Java * [Paul] The W3C CEO is very interested in browser clients. Mary, in your role as chair of IC3 you should meet with him and talk about collaboration. Yesterday I presented the new deck on Higgins, Active Clients and Personal Data Stores. I can send you the link [5]. * [Mary] I'd be happy to if you provide additional background after the call. * [Paul] I will add a link and sent to the list. * [Mike] I want to leave design items until all of the Europeans are on the line. Mary is there other items we should do while we are waiting? * [Mike] I got some email feedback last night. * [Mary] After last week's call I went through all the outstanding third party software programs that haven't yet had IPR reviews. * [Mike] I haven't had the time to go through the list. I need to have Sergey look at the list and let me know and then get back to you. He is working on a higher priority items. I will talk to him about this. * [Mary] Ok. Next is OpenID4Java. John is there any news? * [Mike] Based on the diff file, there is so little change involved. They should have had him send a bug report. The changes could have been made by anyone. 2. [Mary, Tom] What is the plan for the Eclipse/Higgins/Mydex press release? * [Mary] Next is the press release. * [Mike] Tom is typically in transit this time of day. * [Paul] What needs to be done? * [Mary] We are running out of runway. * [Paul] I will send an email to Tom and I this AM. * [Paul] Tom is not on the call. Have a call with Tom after this call. * [Mary] OK. 3. [Paul] New deck on Higgins, Active Clients and Personal Data Stores [5] * [Paul] Next item, there is a link. We could add this link to the webpage and label it Paul's ramblings about Higgins, so it isn't an official position. This was done in preparation for the WC3. They wanted info about Higgins and active cards. Next week there is another briefing. They feel they can bring an international flavor to this conversation and credibility and bring the browser vendors to the table. I would like to combine IC3 and WC3 to see how there is opportunity to collaborate. Some may be interested in that, I'm guessing. * [Link has been added to the Higgins home page.] 4. [Paul, Alexander, Mike] App-card design review [2,3,4] * [Paul] Now we are on to the links about app-card and app design. * [Mike] Those are left over from last week. * [Paul] Click on one of those app card links. It takes you to the personal page; scroll to section 10 of the persona - template .owl - is an entirely new vocabulary. I will review it. * [Paul] I introduced a new kind of context: it is like a Swiss army knife. The idea is that . I made a change to the Higgins data model and I added to the context a pointer to a context to control attributes, so a context can point to a context that will control it (define it in some ways.) This controls what a control context can have in it. The main class is the template class context. I will walk through the several contexts below that. I am cross posting in a Skype window. * [Paul] Or should we use IRC? * [Mike] I know I need to start using that again. * [Paul] The first one is an app data attribute. Basically a change has been made, we had an app data type context and we changed it in a small way. Click to the section on 14 (app data, HOWL) in that overview, now an app data context has .. now holds it in a data instance rather than in the context. Now we can go back to section 10, and we can see why that was a convenient change to make. Now a template context can have an app data attribute and point to an instance of app data. A template context is a more general purpose thing than an app data context or a mapping context. If you had an app card, you would have a pointer to a template context and in the template context would have an app data value pointing to an app data instance.. * [Mike] Can I restate that? The way an app card developer takes advantage of this is they create a template context and populate it with a template for the mapping context or exactly what the context is and this will be in the PDS with global read permissions. When this is installed, something about the install process will read this template and instantiate it. May get pointer to the mapping context or some instantiation of same and pointer to app data or instance of the app data, where template values are replaced by user values. By processing this template, it knows about all the different contexts within the users PDS that are needed. Is that how this is working? * [Paul] Yes. * [Mike] Some of the questions are: you can't just copy the template, because any UDI's are put into a template version of the UDI, not the user specific copies. * [Paul] Are there any UDI's like that . * [Paul] The app data object itself is the common stuff, then there is the per user stuff. We don't have a template for the persona node inside the app data. * [Mike] One thing missing from last week's updates was the JavaScript link to the import handler * [Paul] I didn't add it, and I didn't add the list of API's to call. * [Mike] Do you understand why we need it? We need some way . * [Mike] App event handler URL. * [Paul] So the main JavaScript is not listed. the app rule, you get from Kynetx is determined by app id. * [Valery] They have separate ... to make it generic need to have JavaScript injected by.. * [Paul] So app service type can be set to two values, Higgins (undefined) and Kynetx. * [Mike] Idea is how to document this. We could leave it up to the developer, or we host their JavaScript so that we can make sure they are behaving. If we want to host it, we need to define some rules for how this works for our benefit. If we want to let them do it, we need to do a lot of work to specify this. If at some point we want to define this service, maybe we specify an additional service. For. now, having separate URL is more pragmatic. Easy for us to doc what is going on and for developers. * [Paul] Sure. * [Paul] Someone just needs to propose the changes. * [Mike] I will rewrite the proposed changes. And sent it to the Higgins dev list as a proposal. * [Paul] Make a contract delegate to the app data class. Should make logical renames. * [Mike] There will be app card specific processing that the developer has to do. Hopefully we can do that inside the JavaScript. * [Valery] To make sure we have code for Oct 11, we need to create some sample files. * [Paul] I have a complete template file in there, but it is not a specific one. I don't know where to document the app card wiki extension. It will point in section 13. document this extension on the app card wiki page. * [Paul] The next one is authnmaterials. There are a number of attributes need to make a UDI dynamically resolve. Look at UDI meta data class and click on the anchor 3 link for the document with Markus' service endpoint. Right now the only possible value for authnmaterials is user name and password. You also need a context type. * [Mike] Developers need real concrete examples including the backend template stuff.... * [Paul] Valery to make changes. * [Mike] If make them look like UDI's might be confusing. If make them look like URL's.. * [Mike] If make them URL's, the question is what we can do now to make transition to UDI's easier. [1] http://www.eclipse.org/projects/project-plan.php?projectid=technology.higgin s [2] http://wiki.eclipse.org/Persona_Data_Model_2.0#AppCard [3] http://wiki.eclipse.org/Persona_Data_Model_2.0#app-data.owl [4] http://wiki.eclipse.org/images/0/0b/UnderstandingAppCards.pdf [5] http://www.slideshare.net/ptrevithick/higgins-active-clients-and-personal-da ta-stores-v2
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
