cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: [RT] Source extensions
Date Thu, 09 Oct 2003 19:10:14 GMT
Hi Guido,

Thanks for your reply. See the comments inline.

Guido Casper wrote:
> 
> Hi Unico,
> 
> first let me say thank you for all you efforts in this area. I'm very
> excited about that (I start wondering ...). I'm sorry I cannot help
out
> more currently.
> 
> Unico Hommes <Unico@hippo.nl> wrote:
> > Hi,
> >
> > This is to let you know I've just submitted a patch [1] to cocoon
> > bugzilla for some enhancements to the SourceInspector code. It
solves
> > the problem of more efficiently finding specific properties than is
> > the case now. You may also be interested in a related patch [2] I
> > submitted earlier for basing SourceDescriptionGenerator on the
> > emerging TraversableGenerator that is now still in the scratchpad
> > area. I hope you like the enhancements and look forward to any
> > comments or questions you may have.
> >
> > One of the things I've noticed that I would like to discuss is that
> > the Source extensions such as LockableSource, InspectableSource,
etc.
> > are currently all located inside the Slide block, whereas they
should
> > probably be located in a more general block (a repository block?) or
> > else move them to excalibur sourceresolve.
> 
> I thought about that as well. The problem is that some of them do not
> seem general enough to move to excalibur. I'm +1 for a separate block
> although I'm not sure about the name.
>

Yes, a separate block seems more obvious to me too, at least for some of
the functionality. Property management may be general enough for
Excalibur imho.

> >                                    ---- SourceProperties ----
> >
> > A SourceProperty is a piece of meta data in the form of an XML
> > element that can be associated with a Source. Currently the API
> > separates 'live' properties from 'computed' properties by handling
> > them in different ways.
> >
> > Computed properties are handled by components that implement the
> > SourceInspector interface [3]. Current implementations include
> > [Image]SourceInspectors that support 'width' and 'height' properties
> > and an XPathSourceInspector that queries a Source its XML content.
> > Modifiable properties on the other hand seem to be covered by the
> > InspectableSource interface [4] that has methods for setting and
> > removing SourceProperties.
> >
> > As these interfaces seem to partly overlap I think it would be
useful
> > to try and merge them or choose between one or the other. What I
like
> > about SourceInspector interface is the ability to plug in different
> > implementations of property handlers. We could extend the function
of
> > SourceInspectors to support writing SourceProperties and then
> > deprecate InspectableSource. Off course the SourceInspector would
> > have evolved into something else that would probably be better
> > described by a different name (SourceDescriptor?). This would allow
> > the definition of different datasources for storing SourceProperties
> > too. (I actually have a use case for that).
> 
> I like that. A SourceInspector implementation for inspect-enabling any
> ModifiableSource. 

Not necessarily ModifiableSource but just Source.

> Another step forward (besides RequestFactories) for
> making Cocoon a great WebDAV Server.

Actually, enabling Cocoon as a WebDAV server is the main reason I'm
interested in this.

> However I still feel the SourceInspector covers a different need than
a
> natively inspectable source. It sort of enhances source
implementations
> with additional properties. A natively inspectable source does not
need
> a SourceInspector for ordinary explicitely managed properties (with
> read/write access only through the InspectableSource interface).

True, but again the downside is that clients need to be aware of two
ways to approach SourceProperties.

> However I'm +1 making the SourceInspector support modifiable
properties.
> 
> >
> > As individual Source protocols may have their own way of storing
> > properties (f.i. a WebDAV Source), special SourceDescriptor
> > implementations will still be able to cover those situations
> > elegantly.
> 
> As it stands today the SourceInspector does not (and should not) care
> about the source implementation so it works with any source.
> 
> But I may be just missing the point.

You might ;) I admit that I wasn't very clear so let me explain. Suppose
you have a particular SourceProperty you want to expose that is stored
on a separate WebDAV server. A SourceInspector implementation could look
as follows:

WebdavSourceInspector {
   
   SourceProperty getSourceProperty(Source source, String uri, String
name)
   {
      if (source instanceof WebdavSource) {
         // we know where to look
         davLocation = source.getURI();
         return propfind(davLocation,uri,name);
      }
      return null;
   }
}

You are right that the inspector is aware of a concrete Source
implementation in this particular case. OTOH that is why it is called
WebdavSourceInspector.

By the way, I am not adamant about this, just looking if the API could
be made simpler.

> I could however imagine a special Source implementation that will be
> configured for which SourceInspector implementation to use to
> inspect-enable  modifiable sources (like FileSource).
> 
> >
> >
> >                                 ---- Other Source meta data ----
> >
> > The other Source extensions that exist in the Slide block all deal
> > with a seperate area of meta management of Sources. Except for
> > VersionableSource interface I have not reviewed them very well yet
> > but am wondering inhowfar these could be covered by just
> > SourceProperties (I am just guessing here). At the very least I am
> > concerned with the fact that implementing all these different
> > interfaces leads to rather large class definitions.
> >
> > Comments?
> 
> I share the concern that the Source classes get bigger and bigger.
> However I fail to see how outsourcing the inspectable part solves the
> problem in general. I think this should be decided from case to case
> (LockableSource comes to mind).
> 
> Not being familiar with JSR147 or JSR170 I wonder how these approaches
> deal with it. BTW wasn't a JSR170 draft available somewhere?

Funny you should mention this because I started to take a look at the
proposal just now (it's in the Jakarta-slide repository). I must say it
looks quite impressive and it made me wonder ... (or should I say
dream). From what I can see it deals with the same problem we are trying
to solve with the Source abstraction (possibly less the scheme extension
part).

B.t.w. would it be legal to put the generated java documentation for it
online somewhere. We'd have something to talk about.

> For the WebDAVSource (being based on the Slide webdav client lib) it
> would be more convienient (implementation-wise) to leave the
inspectable
> code there.

OK.

Regards, Unico



Mime
View raw message