I thought we already had Apache available and it was just a matter of configuration to make webdav available. Is there this be a Jetty Servlet webdav we should use instead instead?
No. Just nice to have it all bundled in one server. In this case you
will have two servers - Corona server and Apache HTTP server. But it is
not an issue currently. I do not have experience with setting up Apache
HTTP server.
Regarding FTP - yes I think should eventually have an FTP client repository adapter. There is an Eclipse FTP client plugin we could probably wrap into a repository adapter. I thought we could use the experience Edyta is gaining from working webdav in Jackrabbit to get the webdav implemented quickly. Do you think FTP would be better to do first?
No, I think WebDAV is a better choice. HTTP is always the best choice
in terms of firewalls. If HTTP doesn't go, probably nothing would go.
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
- How to access those information (or protocol); if it a local
file, WebDAV, FTP, JDBC or web service call.
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.
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. But it is not automatically matched and there is no
magical composition of layers depending on description.
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
- the same format parser is kept only in one adapter, instead of
having it in several places
- 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 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.
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.
|
