[corona-dev] content-type and access-type issues

["Everitt, Glenn" <Glenn.Everitt@xxxxxxxxxxxxx>]

I thought the division was Page Views know how to handle content-type and Repository extension points handle access-type.  So the viewers handle reading and display of files whereas repository adapters handle access to files.  So many views still have to written but maybe not as many repository adapters.

Excerpt from Marcin’s earlier post (12/12/2006 9:33 AM)

 

>>I thought the division was Page Views know how to handle content-type and Repository extension points handle access-type.  So >>the viewers handle reading and display of files whereas repository adapters handle access to files.  So many views still have >>to written but maybe not as many repository adapters.

>
>It it not quite like this. It would require three parameters to have it in this way. I was pointing it some time ago. Just to point what information we really need:

·        >what is stored in repository - team members, bugs, tasks, requirements, etc.

·        >what is the format of stored information; it is not only if it is an XML but also the format of XML itself; for instance Bugzilla XML format will be different than >TestTrack XML format, but still they represent bugs

I thought  content-type would be specified as Bugzilla Bug, TestTrack Bug so we overloaded the content-type to indicate both: content-format and content-type.  I agree we should change this into the 3 items – as you mention below but this is a problem of heterogeneous resources in a single repository like CVS, SVN, Jackrabbit, Webdav

access-type – repository connection type

content-type - more general description of the repository contents (bug, team members, source files)

content-format – this should be very specific description of resource formats but   

we don’t know all of the resources types that may exist in a repository.  So specifying all formats in a repository wouldn’t be easy or even possible ahead of time.  So, we need to rely on information from the resource itself.  We have talked about using mime types of files in Jackrabbit to associate a file with the correct viewer.

 

·        >How to access those information (or protocol); if it a local file, WebDAV, FTP, JDBC or web service call.

I think we should include Jackrabbit here.

>So, we have 3 information we need but only 2 places to store it - content-type and access-type. So how did we split it? Simply:

• >We need to select what is in some repository, so the 1) information goes to content-type. The content-type says what information are stored in a given repository. >This will be for instance "bugs". Now, if you work with a RepositoryAdapter for a given content-type, you make an assumption that objects it returns always have >the same interface. I think SDO is going to be used to define interfaces for a given content-type.
• >Then we have still 2 and 3 information to store, but only one field left. So it is merged. So, in fact the access-type meaning is combination of format and way of >accessing it.

No, I think access-type only tells you how to access a repository.  The format is really part of the resource, not of the repository, I think we need a way to ask the resource about its content format.

>As you see you need to implement a new repository adapter for the same XML format if you have it in WebDAV of FTP. Of course you may use some "tricks" with >delegation, and register the same repository adapter for various protocols.

 

I think you mixed up content-type and access-type.  I think you would register the repository adapter with a single protocol.  I think the ViewPage accesses the repository to show list of resources.  Once user chooses a resource to view a mapping of the resources’s content-format to content Viewer must be made.

 

>But it is not automatically matched and there is no magical composition of layers depending on description.

There was a conversation about mapping content-type to Viewers back on 7/31/2006 the email subject was ”RE: [corona-dev] Test Data Moved”

>I'm generally for having it layered into three levels. It would unfortunately mean some complication in CC format as well in matching, but on the other hand we would get:

• >better code reuse, abstraction level
• >the access level (like WebDAV, FTP, etc) could be reused by other repositories if a strict interface is defined

I think currently our strict interface is IRepository

• >the same format parser is kept only in one adapter, instead of having it in several places

Not sure what this means

• >much bigger flexibility
• >the adapters would be composited by format and access protocol; you could then have compositions that wasn't previously thought of - for instance the >team member file could be kept in CVS; now you would have to rewrite adapter so be prepared for this; if we have three levels then in some deployment >environment some commercial plugin with this access type could be provided.

>Probably 3 layers as well doesn't cover all cases, but at least the basic one. Unfortunately our format doesn't allow extending the definition.

 

I thought we could just add this to our ContextContainer model and generate code – some code will have to be changed to use the attribute

 

I suppose this is an SDO issue. >It would be best that content of subtag would be dependent on its type. Then you could always provide as many layers as you need in a particular case.

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.