Hi all, here some short and unmoderated notes from the (skype) team meeting this morning which was attended by Marcel, Ivo and myself. Feel free to comment, For info and input on upcomming meetings please refer to http://www.amdatu.org/confluence/display/Amdatu/Team+meetings.
1) Gadget Container Cloud Service 1.0 There is concern that there is a mismatch between what the board expects and what is actually being worked on. While Martijn put up "Gadget Container Cloud Service 1.0" with ETA January 1st, Ivo is mainly working on a "Demo EC2 Deployment" that is NOT releasable software. It is mainly scoped on a private email conversation between Ivo and Martijn. Some facts: * Ivo is working on a "demo" for Januari 1st * This demo contains forked platform code * This demo contains additional sandbox code * This demo is not an Amdatu OpenSocial * This demo is deployed on one EC2 node (no cluster / no ami) It is important to get this aligned and Ivo will get in touch with Martijn to make sure there are no misunderstandings. After we got this straight the remaining discussions where on the Open Social / Gadget Container service not the demo scope 2) Discussion on “Dashboard Plugin” This is a module is a generic JQuery plugin with some supporting demo html/js files. Hence the name. It has nothing to do with open social of gadgets. The only thing is that the opensocial dashboard implementation uses this plugin. Some further notes: * The OpenSocial dashboard uses the dashboard plugin at the frontend (js) * The Dashboard plugin reasons about widgets (“Generic UI concept”). NOT to be confused with W3C widgets. * The OpenSocial dashboard reasons about gadgets. Thus referred to as widgets in some contexts and interfaces. * The module contains wrong headers and minimizer stuff as Marcel already mentioned in his input mail. (JIRA issues to be created) It is confusing and widgets maybe a little overloaded term as it is also used for W3C Widgets. With this scheme it is not unthinkable that we will end up with methods called getWidgets() that return Gadgets mixed in with Gadgets... if you catch my drift. It seems it would make sense to at least confine the widget reference to the JQuery plugin. 3) Discussion on Gadget Management The current Gadget Management is not a clean whiteboard style as it uses both whiteboard services and an embedded persistent store. This is considered an undesirable implementation as it mixes/violates patterns. The preferred way would be to (re)move persistence gadget configuration to the other side and let that component publish services as well. (JIRA issues to be created) Gadget categories are implemented in a strange way. The provider whiteboard services return POJOs with meta-data instead of providing it directly and possibly and preferably through the service registry. For example GadgetDefinition has it's own ranking and GadgetCategory is a simple id/name pojo. Q: Why are Categories there at all? It is an arbitrary concept now hardcoded/wired into gadget-management. Long discussion followed about (not) making or forcing implementation choices onto applications at the platform level versus application defaults and ease of development etc... no real consensus yet? However, a compromise can be found in a more modular design AND implementation. So in this example categories can be an optional high level feature addon implemented as such allowing anyone to not use it. (JIRA issues to be created) 4) State of Shindig Questionable. Not too much activity, but not zero. No known alternatives. Look into Rave as they have the same requirements. Maybe we could team up and even proffit from their work as well. 5) Planning and more We briefly discussed planning and expectation in relation to the Gadget Cloud Container Service. It also seems a little strange that Identity was moved back as we will need to solve the authentication/authorization mechanism for all cloud services. Conclusion is that we can move the cloud service back, but we may need to move the mechanism forward because of these dependencies. To be discussed. Actions: Marcel : Create JIRA issues for changes from analysis/discussion Bramk : Map OS container to multi-tenant model 0.3 possible dependencies. Ivol : Start gadget container design (scope / use cases / rest interfaces) Ivol : Discuss GCC vs Demo with MvB Ivol : Discuss Auth prio vs GCC and Status: Ivo : Working on Amdatu BigData 0.2.2 Marcel : Create issues Bram : 0.3.0 dev / test Finally, note that most of use are unavailable over the coming two weeks. Next meeting is scheduled for January 9. 2011/12/19 Marcel Offermans <[email protected]>: > Hello guys, > > In preparation of the meeting about the Gadget Container Cloud Service, I've > gone through the current implementation of our open social code. Obviously, > we should carefully design the actual REST services we want to expose when > people start using this and look at the internal design of this project. > This design is currently not on our wiki as far as I can tell. > > I started looking at the opensocial.shindig module, and the first thing that > came to mind is that, with the new multi tenancy model coming up in the > Amdatu Platform 0.3 release, it might make sense to start refactoring the > project to use it soon, since we only implemented multi tenancy as a quick > fix anyway (see http://jira.amdatu.org/jira/browse/AMDATUOPENSOCIAL-42 for > more background, it defines the work that still needs to be done > in http://jira.amdatu.org/jira/browse/AMDATUOPENSOCIAL-113 but I would argue > that it does not make sense to do this in the "old" multi tenancy model > anymore). I do think we need the "proper" model in place if we want to > provide this as a cloud service. Having all tenants in the same Shindig > container does not feel right. > > Some other remarks about this module: > > PersonServiceDispatcher.getPerson() has a rather disturbing TODO in it that > mentions: "For now we just loop over all tenants and see if one of them can > identify the person we are looking for.". That method also fails to check > for nulls, and does not unget the services it gets. > OAuthTenantAwareStoreImple contains a comment: "this doesn't work properly > in flexible environment where gadgets are added and removed from the > store continuously". That needs to be addressed as we will do that. > Like the platform does, this project should default to the bundle data area > for storing information, instead of "work/shindig" (see > ConfigurationAdminGuiceModule). > Related, in AmdatuContainerConfig we should drop the system property > "amdatu.dir". > > Next up, I looked at opensocial.gadgetmanagement, where I started with the > REST services, which seem to be responsible for two things: > 1) providing a REST API to the dashboard > 2) providing a REST CRUD API for gadgets > > These seem to be provided by a combination of two classes and a base class > both of them inherit: BaseRESTServiceImpl that is extended by both > GadgetManagementRESTServiceImpl and WidgetRESTServiceImpl. > > The first contains: > /gadgetstore > /status > /categories > /gadgets/all > /gadgets?uri=... (GET/DELETE) > /gadgets?uri=...&category=... (POST) > /authorized > > The second contains: > /widgets > /mine > > Again, some remarks about this design: > > the split seems rather arbitrary to me, and does not align with the two > different responsibilities (dashboard API and CRUD API for gadgets) > why use both the term "gadgets" and "widgets"? what is the difference? > there seem to be no CRUD operations for gadget categories. > > We also seem to use different methods of registering gadgets right now. You > can do that whiteboard style, or by directly adding it to a store. I would > propose to change this so we always use the whiteboard. The gadget > management component would then listen to two different "services": > > GadgetDefinition, which probably should be an interface, and which sounds > more logical to me than the GadgetDefinitionProvider that is now picked up. > I would just drop the latter completely, it simply lists GadgetDefinitions, > which is not that useful. > GadgetCategory, which should also be an interface, and we should probably > try to eliminate any "hardcoded" categories here. > > So the gadget container itself listens to both, and registers all > definitions and categories it sees. It does not need to persist anything. > All it needs to do is react to the services. > > Using this as a basis, we can add two optional bundles to do: > > REST style registration: Via the REST API there are CRUD operations for both > gadget definitions and categories. Somehow these operations need to be > persisted (optionally). Eventually, these will lead to GadgetDefinitions and > GadgetCategories that are registered whiteboard style. > External gadgets via configuration: Those will also be registered whiteboard > style. > > A question I have: Why did we introduce gadget categories? Is it essential > to have them or can we also work without them, or with some other "grouping" > mechanism such as the tags that GMail uses? > > Another question: OpenSocialContainer suggests independence from Shindig, > but can we really implement this interface differently? To be honest, when > reading the documentation of the interface, I don't really understand how to > implement it. > > Final question about this bundle: Why doesn't the whiteboard currently work > for external gadgets? It complains that it supports only relative URLs, but > why? > > On to opensocial.profile, where I have a couple of smaller remarks: > > PersonService.setFriends() this is the only method that uses an ID of a > friend, everywhere else we use either "Person" or "User". Also, everywhere > else we use List<X> instead of X[] > Why is SerializablePersonImpl part of the API? > What's the point of a Friend (since a Friend is a Person)? > PersonServiceImpl uses serialization, which will fail when you update the > bundle with classes that contain incompatible changes. I know that can be > fixed partially by only doing compatible changes, but bundles can be > upgraded and downgraded at will, which will eventually break this model. > > And finally, opensocial.dashboardplugin: > > It contains a readme that uses yuicompressor, which compacts javascript. Why > is this not part of the normal Maven build? > > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
