Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [corona-dev] content-type and access-type issues 


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.
OK, so this is the difference in undestanding we have. And it seems it is more difference between client and server needs. From my perspective content-format was merged into access-type, not into content-type. But if we want to have viewers for specialized formats thet having content-type and content-format merged would make sense. I was always wondering if for instance we can make bugs view generic enough to handle different types of bug tracking systems. If the assumption is that each bug tracking system makes its own view, than it would be OK.
But where the content-type undestanding went from? For instance we need the team member repository. Now We use something like Corona XML Team Member Repository. In the overview page I want to display number of members in the team. I cannot base on "Corona XML Team Member Repository" content type, because in some deployment someone may use "Company X Team Member Repository", so I need simply the "team member repository", don't care about the format. So format can be only in access-type, am I right?
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.
Yes then we would have it much simplified. The repository adapters are simply for "access-type". Viewers would be in general for "content-format". The "content-type" would then be for finding repositories with some higler level content.
But then we would need to have some kind of "content parsers". Use case again with team repository. The XML file is kept in JackRabbit. The repository adapter returns content of the file. The overview page wants to know how many team members there are. So we provide some "content parser" (or reader) which returns all members in the team. It does it by reading file from repository adapter, parses it and return user records.
But then I think the repository adapter should have a method like getResouceStream(). Again the XML team member. It might be kept in: file, WebDAV, JackRabbit, CVS or BLOB DB field. The input stream would make it parsable nomatter where would be storred. What would now return the "fetchResource()" methods in repository adapter for all those access-types?
· >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.



Sure.
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.
You mean the "fetchResource" method should return and object which contains method "getFormat()"? Might be. It could then have also methods getStream(), getLocalFile(), getURL(), etc.
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, an 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.
Who is mixing content-type and access-type depends on context and needs :) As said before - depends where you put the content-format.
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
Would both content-type and content-format be in RepositoryDescriptor element?
I'm really glad that this time this has been clarified. But difference in undestanding basic contecepts in the team makes me worry a bit ... we must discribe it very clearly to others. 

Marcin
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.

Back to the top