Corona CC Model Changes

First of all I think we need to define use cases and see if we can support it with current model.

SystemContainer

Glenn Everitt

Since we plan to force all events to associated with a container I think we still need a way to post events that destined for all Containers. I think we should allow the SystemContainer to broadcast event to all ContextContainers by using its postEvent() method

ContextContainer

Dennis O'Flynn

The ContextContainer (and ProjectContainer) classes are generated from an EMF model. Additional methods need to be added to these classes as well as updating the functionality provided by some of the generated methods.

• Modify our usage of EMF to generate the model from annotations from the ContextContainer interface instead of schema
• Create a JET template to use by EMF/SDO code generation to merge new functionality as well as update existing methods
• ContextContainer.postEvent()
  • Estabalish the only way to post a container event is by using the container's postEvent() method.
  • Refactor non-container event posting mechanisms as internal.
  • Annotate the postEvent() for WS-Notification
• ContextContainer.addEventHandler()
  • Estabalish the only way to add a container event listener is by using the container's addEventHandler() method.
  • Refactor non-container event handler mechanisms as internal.
• ContextContainer add/update/delete methods
  • embed within each add/update/delete methods an invocation of postEvent() to notify the collaboration environment that the container has been modified.
• Common ProjectContainer functionality
  • Refactory ProjectContainer to move any non-Project specific functionality to the ContextContainer

Merge PCC and CC.

Pawel Kaczmarek

There are VERY few operations that are specific to ProjectContextContainer. The separation of the two causes many unnecessary packages and classes to be created and maintained. The idea behind CC and PCC was to support extensibility, however, the classes are so highly integrated within Corona that it is doubtful if anyone will want subclass CC or PCC.

Probably it will be faster to leave PCC and merge CC into it.

I think it is good idea. There is a proposal how to move PC Manger to generic CC Manager -- Marcin Okraszewski

Merging CC/PC Objects Not a good idea. -- Dennis O'Flynn

• The ContextContainer is part of the collaboration framework.
• The ProjectContextContainer is part of the exemplary implementation
• If the two are merged, how would we show an example of how to build a collaboration solution?

Does the PC need to be modeled? -- Dennis O'Flynn

• I question the value of modeling PC. The value provided by PC is in the validation and use of repositories defined within the CC. I am not aware of any additional data items used by the PC (beyond what CC provides) that would require serialization (via EMF/SDO).
• Could / Should the PC be a class that extends ContextContainerImpl?

Merging CC/PC Objects - NO -- Glenn Everitt

• I don't think we should merge the ContextContainer and ProjectContainer.
• The ProjectContainer is not near complete. New items that could be added include:
  • Project Task List
  • Project Process
  • Project Status

OK, I'm convinced. -- Marcin Okraszewski

Content-format attribute in repository - bug 168680

Marcin Okraszewski

All details in the bug.

Rename URI attribute to ID

Marcin Okraszewski

The name of URI attribute is misleading. Its primary function is ID. It is intended to keep URI form to keep uniqueness and be easily used in external RDF. But the URI suggests that it carries some kind of connection information, which it doesn't.

I agree that this can be misleading. -- Dennis O'Flynn

• If it (URI) is an ID, call it an ID.
• If it is an URI, than return a URI

Resource id for content adapter

Marcin Okraszewski

We intend to make a layered architecture there there is repository adapter and content adapter. The content adapter would parse resource returned by repository adapter. So, the content adapter needs to know the argument to call fetchResource() with.

Eg. We have a team member XML file in CVS. Repository adapter is used to connect CVS. Content adapter is used to parse the file. But how the content adapter know which file to choose?

Should it be some predefined repository connection?

Probably the best way would be simply a parameter with the resource to fetch. The repository anyway this is the "content adapter" that would need take the parameter, so it can simply take a parameter. -- Marcin Okraszewski

Repositories as an external entity ; repository events ??

Marcin Okraszewski

Comes from a pretty simple use case. We have a repository which is added to two containers (A and B). Now someone changes state of the repository (eg. removes a resource), but in container A. The event is sent in container A. An other user that works with container B is not aware of the change !!!!!

This leads to a point that maybe repositories should be detached from CC. CC would contain only a reference to a repository. That would mean that either we would have to provide also repository events or propagate the event in all CC that refers to repository.

I need to think about this some more but I like the idea. What if we created a RepositoryManager and we stored the RepositoryDescriptors in the Repository Manager rather than the Container. The Container would only hold the Name of the RepositoryDescriptor. If a RepositoryAdapter was needed the RepositoryManager would find the repository descriptor with the specified name and then call the RepositoryAdapterFactory to instantiate a RepositoryAdapter and then add the Container as a RepositoryAdapterListener. This way every Container referencing a repository would receive a notification about repository changes. The other nice thing is that sharing repositories such as the TeamMemberRepository is very easy it is now just the name of a RepositoryDescriptor held in the Repository Manager. I think this solves many of issues that we had with related containers. When the RepositoryAdapterListener is registered a filter could also be registered. I think the Container would hold the filter and pass that when it requested a RepositoryAdapter. -- Glenn Everitt

Just one thing - I would make the reference by ID, not name. -- Marcin Okraszewski

Tree structure of containers (subcontainers) - repository inheritance

Marcin Okraszewski

At the very beginning we had an approach that containers would be organized in tree structure. Then we have changed it into "related containers". Why don't we have both?

Why? Look into definition of containers for Corona project. There are a number of containers: Corona, Corona Development, Corona Client, Corona Server... Each of the containers need to contain a team member repository, which is the same for all of them. Eg. Bugzilla is similar case.

If we had a tree structure of containers and provide a new flag in repository ("inherit"), we could solve it. Note that the system container is intended to contain other repositories, so the mechanism of sub containers need to be available anyway. In this way for instance we could define a default event router for all containers at a single server.

Rename "repository" ?

Marcin Okraszewski

The repository element is used not only for describing repositories. It keeps web service descriptions, event router settings, etc. This was pointed and suggested at other page connected with API changes: Corona CC New Approach.

For now seems like repository element is used to keep information about anything that is connectible. Maybe it should be named connectibleElement?

Any suggestions on the new name? ContextProvider

I don't think we should rename repository -- Glenn Everitt.

A repository just holds artifacts. If we want to keep service descriptions, and service connection information I think we should call them something other than a repository because they are different. How about ServiceReference?

But take a look for team member repository accessed through WS. Is it repository or is it service? In addition, we provide a whole infrastructure for handling with repositories, matching with adapters, etc. Adding a new element, eg. ServiceReference, requires a new "adapter" infrastructure for this. Having something more generic gives us an ability to reuse lots of code. And I think that you can say what are you dealing with by the parameters (content-type, content-format, access-type). -- Marcin Okraszewski

Reference between repositories

Marcin Okraszewski

Described in details in stackable repositories section at an other page.

Free form part in repository descriptor

Marcin Okraszewski

In general property-value model not always is enough. Maybe it would possible to have added a "free form" xml element in each element. A repository adapter of a given type would know how to use it then. Obviously usage of this element wouldn't be required.

Don't know if it is possible with EMF generated model ... I'm afraid not. For sure it is possible in XML Schema. Repository adapter could access those information for instance in a DOM form.

Free form part in repository descriptor has problems. -- Glenn Everitt

The class org.eclipse.emf.ecor.sdo.EDataObjectAnyType looks like it is for handling the elements of type ANY, so I think we could have a free form. I'm not sure having a free form section is a good thing. It means anything entered into this section cannot be validated. It also means we don't have a good way to present it in user interface even for display purposes. I think the example below could be implemented similarly to connection-parameters using name, value pairs which is what is shown.

I agree that validation might be an issue. But there should be installed a schema for name space used. If I remember correctly you can even say in schama that the element of ANY type needs to be strictly checked (schema must be available). The plugin that introduces a new name space could also bring a schema for it.

But how to display it? This something that viewer or adapter would use. The consumer of this extra information would know how to use it.

But what I'm afraid of, is that it would went out of control. That people often would prefer usage of the free form part over the property part. But anyhow, if people use properties of names that you don't know about you don't know how to use them either. This is the matter of standardization. Each repository type needs to be well documented what are the information it expects. Whether this is some free form XML or property doesn't matter so much. The problem is that the structure need to be written down.

For instance if we would like to have repository that invokes a command through SSH, but the command requires some parameters. We could have it like this (element intentionally simplified):

<repository content-type="build">
  <connection access-type="ssh" content-format="command">
    <property name="host">corona.eclipse.org</property>
    <property name="cmd">cd /home/releng ; buildAll.sh {$buildType}</property>
    <extension>
      <user-input name="buildType" label="Please select build type" type="combo" >
        <item value="M">Maintenance</item>
        <item value="N">Nightly</item>
        <item value="I">Integration</item>
        <item value="S">Stable</item>
      </user-input>
    </extension>
</repository>

Without <extension> element it would be very difficult to write and use.

CC as RDF ... I'm dreaming

Marcin Okraszewski

I still believe that keeping CC in RDF would be a good idea:

• everything is done by references
• RDF Schema could provide a default model which could be extended by anyone without influencing the default model; I can make a bet that our model with repositories descriptor and properties within it finally won't work for some case ...
• you can also generate class representation from RDF Schema that isolates you from RDF RDF Reactor
• allows to integrate with DOAP (Description of a Project) - RDF vocabulary to describe open source projects
• easy integration with any SemanticWeb data sources, eg. FOAF
• RDF is future! Almost no scientific project is funded by EU unless it is connected with SemanticWeb
• RDF is about information integration (sounds strange, I know)
• extensibility, extensibility, extensibility ...

Events

Posting of Events

Dennis O'Flynn

All events are associated with a specific ContextContainer. The ContextContainer should (and does) have a method to post events on its behalf. This method postEvent() should be the only way an event is posted for a specific ContextContainer.

Operations within the ContextContainer that change the container's attributes or state should call postEvent() to notify the workgroup that the ContextContainer has been changed.

I like it :) -- Marcin Okraszewski

Handling of Events

Dennis O'Flynn

Components that need to handle events for a specific ContextContainer should register a handler with that container. The ContextContainer should provide (not yet implemented) a method to allow a component to add and remove an event handler for that container.

So again a method, eg. ContextContainer.addEventHandler()? I think it would be very useful. -- Marcin Okraszewski

Local/remote events?

Marcin Okraszewski

Some listeners may want to register only for local or remote events. For filtering client UID could be used, but this means that you cannot make a static filter declared for instance in extension point. Maybe there should be an event parameter that has two (or three) values:

• local
• remote
•  ?? server ??

This would simplify filtering.