Am Mi, den 14.04.2004 schrieb Unico Hommes um 12:09:
> From: Stephan Michels [mailto:[EMAIL PROTECTED]
> > The Repository IFs seems be more helper classes than components. And I
> > think we should using the Source objects instead to reflect
> > all aspects
> > like locking, property handling etc.
> >
>
> Oh no no no please! Stacking up interface upon interface is NOT
> a nice design at all IMHO. I REALLY don't like this. In fact I tend
> to think that a Source should be just the Source interface itself. All
> additional funtionality should come in the form of helper classes,
> again IMHO.
In my mind the Source is nothing more than a peer to connect some kind
of business entity: a file in the FS, or an entry in a DB. All easly to
lookup via a unique URI. The scheme define the realm and select the
implementation. If you try to see the world from the other side, in a
more repository centric way, then you will come more to an API like
Slide. Which implements for every "aspects" a components. This design is
not bad, quite the contrary, I like it. But the problem is that it is
not very OOP.
I try to elaborate this... For example you must create a heavywight
object like a connection, e.g. WebdavResource. Then you must pass this
object to every method call of the "stateless" components, or create
new ones for every call.
Content aspect:
void save(String path, String content) {
Connection c = lookup(path).
c.save(content);
}
Property aspect:
void setProperty(String path, String name, String value) {
Component c = lookup(path);
c.setProperty(name, value);
}
On the other side
MyRealmSource:
Connection c;
MyRealmSource(String path) {
c = lookup(c);
}
save() and setProperty() etc.
}
So, you can store all state information into your peer. With a simple
resolver.resolve("webdav://localhost:8888/webdav/files/index.txt");
you can get access to the correct implementation and a unique business
entity.
So you can say that "if you add all aspects for your source, you will
get a huge one". But as far as I can see is that I don't need much
aspects. The current webdav methods are:
GET PROPFIND HEAD LOCK UNLOCK OPTIONS PUT MKCOL POST COPY MOVE
DELETE PROPPATCH REPORT SUBSCRIBE UNSUBSCRIBE
POLL EVENT TRANSACTION ACL SEARCH VERSION-CONTROL
CHECKIN CHECKOUT UNCHECKOUT MKWORKSPACE LABEL UPDATE
BIND UNBIND REBIND
Which should be enough to do most things, which will be needed.
> > My proposal is to drop the Slide Source, but leave the Slide server as
> > option, and using the Slide block in the same sense as the
> > hsqldb block.
>
> I don't understand your rationale. The Slide Source is there, it may have it's
> uses in some scenarios. Why throw away something that is working perfectly
> well?
I don't intend to throw away any code. I only question the place of
the Slide Source. I wasn't aware that people use it.
> > So that we can use Slide as WebDAV server for our WebDAV examples.
>
> I have been thinking about making the WebDAV samples work with
> Slide as WebDAV server as well. But throwing out SlideSource is
> no prerequisite for that.
No, it isn't. What I really want to see is some kind of admin tool for
a webdav server. Browsing through the files, see different versions,
changing properties etc.
Stephan.
