You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/11/11 16:02:00 UTC
Random comments and bugfixes
[copying dev@cocoon because many people are in search for a serious
versioned content repository these days]
Hello everyone,
I find myself in the need for a serious WebDAV/DeltaV/DASL content
repository and after having searched land and sea and having tried all
possible combinations out there [pure mod_dav, catacomb and
subversion], I decided to use invest my effort in Slide, also because
of the familiarity with the java language compared to mod_dav which
isn't really friendly for me]
I've looked into the tree for a few days now and I found several things
that puzzle me.
[note, I'm running slide as of CVS checkout of yesterday morning, on
Jetty 4.2.14rc1, on MacOS X 10.3.1 with JVM 1.4.2_01]
First of all, I think that "org.apache.slide.util.Configurations"
should *not* be abstract... because it's used directly (via static
methods) from the WebDAVServlet. This caused the "litmus" tests (see
http://www.webdav.org/neon/litmus/) to fail and DeltaV clients to go
nuts since the system was triggering 500 errors while trying to access
the configuration classes.
After patching this, Slide passes all the litmus tests but one:
16. prophighunicode....... FAIL (PROPPATCH of property with high
unicode value)
17. propget............... FAIL (No value given for property
{http://webdav.org/neon/litmus/}high-unicode)
il motivo e' il seguente: org.jdom.IllegalDataException: The data "?"
is not legal for a JDOM character content: 0xd800 is not a legal XML
character.
Here is the HTTP request
PROPPATCH /files/litmus/prop2 HTTP/1.1
Host: 127.0.0.1:10000
User-Agent: litmus/0.9.4 neon/0.24.2
Connection: TE
TE: trailers
Content-Length: 185
X-Litmus: props: 16 (prophighunicode)
<?xml version="1.0" encoding="utf-8" ?>
<propertyupdate xmlns='DAV:'>
<set>
<prop>
<high-unicode
xmlns='http://webdav.org/neon/litmus/'>𐀀</high-unicode>
</prop>
</set>
</propertyupdate>
[Note that I reformatted the output, so the content-length is broken]
Now: whose problem is this Slide's or JDOM's?
- o -
Now a few random questions:
1) what's the status of the tree? I found out that contributed
WebDAVGUI is out of synch with the various libraries and it seems dead.
I also find the distribution waaaaay too tomcat centric.
2) I saw the archives and I heard about the 2.0 release proposal,
what's the status of that?
3) also, what's the status of the variuos stores? are they usable?
4) now a more detailed question: does the DASL implementation provided
with Slide scale? are the content metadata stored in the DB or are
stored along with the files?
[I'm going to investigate #4 myself, but I would like to hear your
opinion]
Thanks for any help that you might give me.
ah, and prepare for a load of patches ;-) [there are tons of import
statements to cleanup, javadocs warnings and unused variables... note:
I don't have CVS access on the slide CVS module, otherwise I would
commit them myself]
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 12:42, Oliver Zeigermann wrote:
> Stefano Mazzocchi wrote:
>> On 12 Nov 2003, at 09:30, Oliver Zeigermann wrote:
>>> Stefano Mazzocchi wrote:
>> I'm using it with Jetty and it doesn't have any problem. But, like I
>> said, I found the process of taking out pieces from tomcat rather
>> painful.. not something that a newbie would do without major having
>> to look into the code to find out what properties go into the
>> slide.properties file and what goes into the web.xml in order to tell
>> where to fetch the domain.xml file.
>
> I have the same *painful* experience...
I have a really clean setup that runs on jetty (which is much more
lightweight than tomcat)
>>> A general DB store is currently being merged and - although there
>>> still are some substantial problems - I am optimistic to have it
>>> runnig soon.
>> I'm working on it right now.
>
> Oooops. Let's see we get no *new* branches since my efforts all go
> into the direction of merging them back together again. What have you
> done so far?
Testing :-) don't worry, I will ask before doing anything substantial.
>>> I proposed to drop all other stores as non of them works correct and
>>> the above stores are developed to replace them.
>> +1, sounds like the way to go. More than anything, users hate "dead
>> code" because it's undistinguishable from "life one". So it should
>> either reside in a "scratchpad" or a "proposal" area of the CVS and
>> clearly delimited as alpha stuff.
>
> Agreed.
cool. So, what code are you working on right now?
>
>> As for more substantial patches, I'll let you decide what to do.
>> Where do you want the patches, here on the mail list or on bugzilla?
>
> Hmmmm. The proper place would be in the bugzilla, I guess. But
> experience showed it did not get too much attention in the past. I'd
> still say, put it into bugzilla.
Ok
--
Stefano.
Re: Random comments and bugfixes
Posted by Oliver Zeigermann <oz...@c1-fse.de>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 09:30, Oliver Zeigermann wrote:
>
>> Stefano Mazzocchi wrote:
> I'm using it with Jetty and it doesn't have any problem. But, like I
> said, I found the process of taking out pieces from tomcat rather
> painful.. not something that a newbie would do without major having to
> look into the code to find out what properties go into the
> slide.properties file and what goes into the web.xml in order to tell
> where to fetch the domain.xml file.
I have the same *painful* experience...
>> A general DB store is currently being merged and - although there
>> still are some substantial problems - I am optimistic to have it
>> runnig soon.
>
>
> I'm working on it right now.
Oooops. Let's see we get no *new* branches since my efforts all go into
the direction of merging them back together again. What have you done so
far?
>> I proposed to drop all other stores as non of them works correct and
>> the above stores are developed to replace them.
>
>
> +1, sounds like the way to go. More than anything, users hate "dead
> code" because it's undistinguishable from "life one". So it should
> either reside in a "scratchpad" or a "proposal" area of the CVS and
> clearly delimited as alpha stuff.
Agreed.
> As for more substantial patches, I'll let you decide what to do.
>
> Where do you want the patches, here on the mail list or on bugzilla?
Hmmmm. The proper place would be in the bugzilla, I guess. But
experience showed it did not get too much attention in the past. I'd
still say, put it into bugzilla.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 09:30, Oliver Zeigermann wrote:
> Stefano Mazzocchi wrote:
>> 1) what's the status of the tree? I found out that contributed
>> WebDAVGUI is out of synch with the various libraries and it seems
>> dead. I also find the distribution waaaaay too tomcat centric.
>
> That's true if you want to use Slide authentication for the container.
> I agree there should be a different solution. Maybe a JAAS
> implementation?
that sounds a good idea to me.
> Otherwise, I used Slide with Weblogic 8.1 and it seemed to work ok.
I'm using it with Jetty and it doesn't have any problem. But, like I
said, I found the process of taking out pieces from tomcat rather
painful.. not something that a newbie would do without major having to
look into the code to find out what properties go into the
slide.properties file and what goes into the web.xml in order to tell
where to fetch the domain.xml file.
>> 2) I saw the archives and I heard about the 2.0 release proposal,
>> what's the status of that?
>
> Well, I just proposed myself for the job of the release manager on the
> user list. If poeple accept me for this job or anybody else volunteers
> for it, (hopefully) few things stand in the way of a first milestone
> release in the near future. Certainly, I will need commit access to
> CVS first, but I am already a designated committer. Do you know a way
> to speed up the administrative process of being granted commit rights
> as there are quite some patches waiting to be checked in?
If the election has taken place and result was positive (at least 3 +1
and no -1), the proponent should inform infrastructure@apache.org and
request commit access for you.
>> 3) also, what's the status of the variuos stores? are they usable?
>
> Unfortunately, this is a genereal NO. I posted a status overview a
> view weeks ago, titled
>
> REQUEST FOR HELP/COMMENT: Store problems
>
> Have a look in the archives.
I will, thanks.
> Anyway, the transactional file store works stable and even faster than
> the DB stores for the basic stuff. It certainly has less potential for
> optimizations and some limitations in scalability and lacks performace
> under concurrent access. Although, still need to check in the current
> version. I could think of this store as the default implementation for
> a download and go version.
I agree on that.
> General caching has been revised as well to support transactional
> control.
Cool.
> A general DB store is currently being merged and - although there
> still are some substantial problems - I am optimistic to have it
> runnig soon.
I'm working on it right now.
> I proposed to drop all other stores as non of them works correct and
> the above stores are developed to replace them.
+1, sounds like the way to go. More than anything, users hate "dead
code" because it's undistinguishable from "life one". So it should
either reside in a "scratchpad" or a "proposal" area of the CVS and
clearly delimited as alpha stuff.
>> ah, and prepare for a load of patches ;-) [there are tons of import
>> statements to cleanup, javadocs warnings and unused variables...
>> note: I don't have CVS access on the slide CVS module, otherwise I
>> would commit them myself]
>
> That's tricky because commits seem to be done rarely and only when
> already in stable state. So, cleaning can cause a lot of conflicts.
No conficts are created by cleaning up statements, javadoc comments and
unused variables. These patches are transparent.
As for more substantial patches, I'll let you decide what to do.
Where do you want the patches, here on the mail list or on bugzilla?
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Oliver Zeigermann <oz...@c1-fse.de>.
Martin Dulisch wrote:
>>Well, I just proposed myself for the job of the release
>>manager on the user list. If poeple accept me for this job or
>>anybody else volunteers for it, (hopefully) few things stand
>>in the way of a first milestone release in the near future.
>>Certainly, I will need commit access to CVS first, but I am
>>already a designated committer. Do you know a way to speed up
>>the administrative process of being granted commit rights as
>>there are quite some patches waiting to be checked in?
>>
>
>
> Oliver, has someone allready send an email to apache
> infrastructure to request the rights? You could also send an
> email to the jakarta PMC. I think they could start the
> administrative process.
Already happened...
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Martin Dulisch <md...@s-und-n.de>.
> Well, I just proposed myself for the job of the release
> manager on the user list. If poeple accept me for this job or
> anybody else volunteers for it, (hopefully) few things stand
> in the way of a first milestone release in the near future.
> Certainly, I will need commit access to CVS first, but I am
> already a designated committer. Do you know a way to speed up
> the administrative process of being granted commit rights as
> there are quite some patches waiting to be checked in?
>
Oliver, has someone allready send an email to apache
infrastructure to request the rights? You could also send an
email to the jakarta PMC. I think they could start the
administrative process.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Oliver Zeigermann <oz...@c1-fse.de>.
Stefano Mazzocchi wrote:
> 1) what's the status of the tree? I found out that contributed WebDAVGUI
> is out of synch with the various libraries and it seems dead. I also
> find the distribution waaaaay too tomcat centric.
That's true if you want to use Slide authentication for the container. I
agree there should be a different solution. Maybe a JAAS implementation?
Otherwise, I used Slide with Weblogic 8.1 and it seemed to work ok.
> 2) I saw the archives and I heard about the 2.0 release proposal, what's
> the status of that?
Well, I just proposed myself for the job of the release manager on the
user list. If poeple accept me for this job or anybody else volunteers
for it, (hopefully) few things stand in the way of a first milestone
release in the near future. Certainly, I will need commit access to CVS
first, but I am already a designated committer. Do you know a way to
speed up the administrative process of being granted commit rights as
there are quite some patches waiting to be checked in?
> 3) also, what's the status of the variuos stores? are they usable?
Unfortunately, this is a genereal NO. I posted a status overview a view
weeks ago, titled
REQUEST FOR HELP/COMMENT: Store problems
Have a look in the archives. Anyway, the transactional file store works
stable and even faster than the DB stores for the basic stuff. It
certainly has less potential for optimizations and some limitations in
scalability and lacks performace under concurrent access. Although,
still need to check in the current version. I could think of this store
as the default implementation for a download and go version.
General caching has been revised as well to support transactional control.
A general DB store is currently being merged and - although there still
are some substantial problems - I am optimistic to have it runnig soon.
I proposed to drop all other stores as non of them works correct and the
above stores are developed to replace them.
> ah, and prepare for a load of patches ;-) [there are tons of import
> statements to cleanup, javadocs warnings and unused variables... note: I
> don't have CVS access on the slide CVS module, otherwise I would commit
> them myself]
That's tricky because commits seem to be done rarely and only when
already in stable state. So, cleaning can cause a lot of conflicts.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 04:09, Michael Smith wrote:
> Stefano Mazzocchi wrote:
>> On 13 Nov 2003, at 00:25, Michael Smith wrote:
>>>>> Java doesn't tend to cope too well (at least not without
>>>>> significant extra effort by the programmer) with stuff outside the
>>>>> BMP. It's probably some sort of bug in JDOM, technically - but I'm
>>>>> not sure about that. It'd be painful to fix.
>>>>
>>>> well, we have a problem of compliance then.
>> as you see in my other email, we don't have a problem. It's the test
>> that is wrong.
>> :-)
>
> Well, as you see in _my_ other email, we do have a problem, because
> the test is correct :-)
Yes, we do. I suspect this is a JDOM bug since the stacktrace I get.
I'm investigating as we speak.
--
Stefano, trying to get to the end of the litmus tests before doing
anything to improve performance (2 errors and 4 warnings to go!)
Re: Random comments and bugfixes
Posted by Michael Smith <ms...@speedlegal.com>.
Stefano Mazzocchi wrote:
>
> On 13 Nov 2003, at 00:25, Michael Smith wrote:
>
>>>> Java doesn't tend to cope too well (at least not without significant
>>>> extra effort by the programmer) with stuff outside the BMP. It's
>>>> probably some sort of bug in JDOM, technically - but I'm not sure
>>>> about that. It'd be painful to fix.
>>>
>>> well, we have a problem of compliance then.
>
>
> as you see in my other email, we don't have a problem. It's the test
> that is wrong.
>
> :-)
>
Well, as you see in _my_ other email, we do have a problem, because the
test is correct :-)
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 00:25, Michael Smith wrote:
>>> Java doesn't tend to cope too well (at least not without significant
>>> extra effort by the programmer) with stuff outside the BMP. It's
>>> probably some sort of bug in JDOM, technically - but I'm not sure
>>> about that. It'd be painful to fix.
>> well, we have a problem of compliance then.
as you see in my other email, we don't have a problem. It's the test
that is wrong.
:-)
--
Stefano.
Re: [litmus] Re: Test 16 is wrong
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 13:12, Julian Reschke wrote:
> Stefano Mazzocchi wrote:
>
>> I did. So this is definately a JDOM bug now.
>> Sorry for the noise :-(
>
> Maybe tis helps: a Java-based XML processor usually uses Java
> characters, and those are (most of the time?) 16 bit values, hence
> Unicode characters beyond 0x10000 will be reported as surrogate pair
> (two chars).
>
> This is correct, and no problem at all.
>
> I except the problem occurs when Java text containing surrogate pairs
> is then serialized back to an XML stream (where the surrogate pair
> needs to be replaced by a single Unicode character).
thanks for the suggestion!
--
Stefano.
Re: [litmus] Re: Test 16 is wrong
Posted by Julian Reschke <ju...@gmx.de>.
Stefano Mazzocchi wrote:
> I did. So this is definately a JDOM bug now.
>
> Sorry for the noise :-(
Maybe tis helps: a Java-based XML processor usually uses Java
characters, and those are (most of the time?) 16 bit values, hence
Unicode characters beyond 0x10000 will be reported as surrogate pair
(two chars).
This is correct, and no problem at all.
I except the problem occurs when Java text containing surrogate pairs is
then serialized back to an XML stream (where the surrogate pair needs to
be replaced by a single Unicode character).
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Test 16 is wrong
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 04:09, Michael Smith wrote:
> Stefano Mazzocchi wrote:
>> Hello,
>> I'm trying to get Apache Slide (http://jakarta.apache.org/slide/) to
>> pass the test and it currently fails two tests:
>> 16. prophighunicode....... FAIL (PROPPATCH of property with high
>> unicode value)
>> 17. propget............... FAIL (No value given for property
>> {http://webdav.org/neon/litmus/}high-unicode)
>> the offending request is:
>> PROPPATCH /files/litmus/prop2 HTTP/1.1
>> Host: 127.0.0.1:10000
>> User-Agent: litmus/0.9.4 neon/0.24.2
>> Connection: TE
>> TE: trailers
>> Content-Length: 185
>> X-Litmus: props: 16 (prophighunicode)
>> <?xml version="1.0" encoding="utf-8" ?><propertyupdate
>> xmlns='DAV:'><set><prop><high-unicode
>> xmlns='http://webdav.org/neon/litmus/'>𐀀</high-unicode></
>> prop></ set></propertyupdate>
>> After looking at the archives, I saw that the above tests were added
>> by a user later down the road.
>>
>> http://mailman.webdav.org/pipermail/litmus/2002-September/000021.html
>> After careful searching, I found that that the test is wrong since
>> since that character is not allowed in textual content as for the XML
>> Specification.
>> By taking a look at
>> http://www.w3.org/TR/REC-xml#CharClasses
>> you clearly see that 𐀀 which is equivalent to � is not
>> a valid XML character, as Slide correctly reports (thru an error
>> signaled by the underlying JDOM library)
>
> 𐀀 is equivalent to 𐀀, not �.
D'oh! I should not do debugging at 4:30AM! You are totally right!
> It's a perfectly reasonable and valid character. See section 2.2 of
> the XML spec at: http://www.w3.org/TR/REC-xml#charsets
>
> Specifically: "Consequently, XML processors must accept any character
> in the range specified for Char", and
>
> Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
> [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate
> blocks, FFFE, and FFFF. */
>
> Note that this precludes using surrogates to encode these 'high
> unicode' values - so you have to do it this way (a Java parser's
> internal format will, I think, use surrogates, however).
>
>> Note that currently Slide returns a 500 (internal server error), but
>> I'm going to patch it to return a 400 (Bad Request) and I would
>> suggest the Litmus tests to be changed accordingly, expecing a 400
>> on the above request.
>
> As described above, it's a valid request, Slide should handle it.
>
> Your error is solely in how you got from 𐀀 to � - I'm
> not sure what you did, or if you just (incorrectly) trusted the value
> that slide was reporting as an error.
I did. So this is definately a JDOM bug now.
Sorry for the noise :-(
--
Stefano.
Re: Test 16 is wrong
Posted by Michael Smith <ms...@speedlegal.com>.
Stefano Mazzocchi wrote:
> Hello,
>
> I'm trying to get Apache Slide (http://jakarta.apache.org/slide/) to
> pass the test and it currently fails two tests:
>
> 16. prophighunicode....... FAIL (PROPPATCH of property with high
> unicode value)
> 17. propget............... FAIL (No value given for property
> {http://webdav.org/neon/litmus/}high-unicode)
>
> the offending request is:
>
> PROPPATCH /files/litmus/prop2 HTTP/1.1
> Host: 127.0.0.1:10000
> User-Agent: litmus/0.9.4 neon/0.24.2
> Connection: TE
> TE: trailers
> Content-Length: 185
> X-Litmus: props: 16 (prophighunicode)
> <?xml version="1.0" encoding="utf-8" ?><propertyupdate
> xmlns='DAV:'><set><prop><high-unicode
> xmlns='http://webdav.org/neon/litmus/'>𐀀</high-unicode></prop></
> set></propertyupdate>
>
> After looking at the archives, I saw that the above tests were added by
> a user later down the road.
>
> http://mailman.webdav.org/pipermail/litmus/2002-September/000021.html
>
> After careful searching, I found that that the test is wrong since
> since that character is not allowed in textual content as for the XML
> Specification.
>
> By taking a look at
>
> http://www.w3.org/TR/REC-xml#CharClasses
>
> you clearly see that 𐀀 which is equivalent to � is not a
> valid XML character, as Slide correctly reports (thru an error signaled
> by the underlying JDOM library)
𐀀 is equivalent to 𐀀, not �.
It's a perfectly reasonable and valid character. See section 2.2 of the
XML spec at: http://www.w3.org/TR/REC-xml#charsets
Specifically: "Consequently, XML processors must accept any character in
the range specified for Char", and
Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate
blocks, FFFE, and FFFF. */
Note that this precludes using surrogates to encode these 'high unicode'
values - so you have to do it this way (a Java parser's internal format
will, I think, use surrogates, however).
>
> Note that currently Slide returns a 500 (internal server error), but
> I'm going to patch it to return a 400 (Bad Request) and I would suggest
> the Litmus tests to be changed accordingly, expecing a 400 on the above
> request.
As described above, it's a valid request, Slide should handle it.
Your error is solely in how you got from 𐀀 to � - I'm not
sure what you did, or if you just (incorrectly) trusted the value that
slide was reporting as an error.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Test 16 is wrong
Posted by Stefano Mazzocchi <st...@apache.org>.
Hello,
I'm trying to get Apache Slide (http://jakarta.apache.org/slide/) to
pass the test and it currently fails two tests:
16. prophighunicode....... FAIL (PROPPATCH of property with high
unicode value)
17. propget............... FAIL (No value given for property
{http://webdav.org/neon/litmus/}high-unicode)
the offending request is:
PROPPATCH /files/litmus/prop2 HTTP/1.1
Host: 127.0.0.1:10000
User-Agent: litmus/0.9.4 neon/0.24.2
Connection: TE
TE: trailers
Content-Length: 185
X-Litmus: props: 16 (prophighunicode)
<?xml version="1.0" encoding="utf-8" ?><propertyupdate
xmlns='DAV:'><set><prop><high-unicode
xmlns='http://webdav.org/neon/litmus/'>𐀀</high-unicode></prop></
set></propertyupdate>
After looking at the archives, I saw that the above tests were added by
a user later down the road.
http://mailman.webdav.org/pipermail/litmus/2002-September/000021.html
After careful searching, I found that that the test is wrong since
since that character is not allowed in textual content as for the XML
Specification.
By taking a look at
http://www.w3.org/TR/REC-xml#CharClasses
you clearly see that 𐀀 which is equivalent to � is not a
valid XML character, as Slide correctly reports (thru an error signaled
by the underlying JDOM library)
Note that currently Slide returns a 500 (internal server error), but
I'm going to patch it to return a 400 (Bad Request) and I would suggest
the Litmus tests to be changed accordingly, expecing a 400 on the above
request.
I would also suggest to change the test to use 龥 instead of
� as it's the highest legal char allowed by the XML
specification.
Hope this helps.
--
Stefano.
Re: Random comments and bugfixes
Posted by Michael Smith <ms...@speedlegal.com>.
>> Java doesn't tend to cope too well (at least not without significant
>> extra effort by the programmer) with stuff outside the BMP. It's
>> probably some sort of bug in JDOM, technically - but I'm not sure
>> about that. It'd be painful to fix.
>
>
> well, we have a problem of compliance then.
I guess so. I suspect it's one that will _in practice_ only come up in
test suites, but in the future it'll be increasingly likely that people
will actually want to use 'high' unicode characters.
Do you know how this _should_ be handled? Does the parser have to
decompose 𐀀 to a surrogate pair? And then presumably compose that
surrogate pair to a single character on serialisation/output (if - as we
usually see with webdav - the output is UTF-8)
Anyway, I'd be very surprised if slide were doing anything internally
that could break this - so I suppose it must be a parser bug. Probably
not a particularly easy one to fix.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 00:00, Michael Smith wrote:
> Stefano Mazzocchi wrote:
>
>> <?xml version="1.0" encoding="utf-8" ?>
>> <propertyupdate xmlns='DAV:'>
>> <set>
>> <prop>
>> <high-unicode
>> xmlns='http://webdav.org/neon/litmus/'>𐀀</high-unicode>
>> </prop>
>> </set>
>> </propertyupdate>
>> [Note that I reformatted the output, so the content-length is broken]
>> Now: whose problem is this Slide's or JDOM's?
>
> Java's?
no
> Java doesn't tend to cope too well (at least not without significant
> extra effort by the programmer) with stuff outside the BMP. It's
> probably some sort of bug in JDOM, technically - but I'm not sure
> about that. It'd be painful to fix.
well, we have a problem of compliance then.
>
>> - o -
>> Now a few random questions:
>> 1) what's the status of the tree? I found out that contributed
>> WebDAVGUI is out of synch with the various libraries and it seems
>> dead. I also find the distribution waaaaay too tomcat centric.
>
> The slide core is reasonably stable and well tested. Likewise the
> slide webdav server frontend. Everything outside of that is in various
> states of disrepair. The distribution might be mildly tomcat-centric,
> the code is not - and since users aren't going to be able to use the
> distribution as-is anyway, I don't think this is a major problem.
True. But I found it rather painful to "dismantle" the distribution to
a point where it had only the bare minimum of what I needed to run into
another container.
What about two different distributions?
>> 2) I saw the archives and I heard about the 2.0 release proposal,
>> what's the status of that?
>
> Under discussion. Looks likely to happen in the next few months.
good
>
>> 3) also, what's the status of the variuos stores? are they usable?
>
> No. They all have either critical correctness or performance problems.
> Work is happening to provide a usable JDBC-based store in the
> relatively near future.
I'm interested to help in that regard. What stores are being worked on?
>> 4) now a more detailed question: does the DASL implementation
>> provided with Slide scale? are the content metadata stored in the DB
>> or are stored along with the files?
>
> The DASL implementation with the available stores is extremely
> non-scalable. Content metadata is stored in the DB if you're using a
> DB-based store, as are the file contents.
ok
thanks for the info.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by Michael Smith <ms...@speedlegal.com>.
Stefano Mazzocchi wrote:
> <?xml version="1.0" encoding="utf-8" ?>
> <propertyupdate xmlns='DAV:'>
> <set>
> <prop>
> <high-unicode
> xmlns='http://webdav.org/neon/litmus/'>𐀀</high-unicode>
> </prop>
> </set>
> </propertyupdate>
>
> [Note that I reformatted the output, so the content-length is broken]
>
> Now: whose problem is this Slide's or JDOM's?
Java's? Java doesn't tend to cope too well (at least not without
significant extra effort by the programmer) with stuff outside the BMP.
It's probably some sort of bug in JDOM, technically - but I'm not sure
about that. It'd be painful to fix.
>
> - o -
>
> Now a few random questions:
>
> 1) what's the status of the tree? I found out that contributed WebDAVGUI
> is out of synch with the various libraries and it seems dead. I also
> find the distribution waaaaay too tomcat centric.
The slide core is reasonably stable and well tested. Likewise the slide
webdav server frontend. Everything outside of that is in various states
of disrepair. The distribution might be mildly tomcat-centric, the code
is not - and since users aren't going to be able to use the distribution
as-is anyway, I don't think this is a major problem.
>
> 2) I saw the archives and I heard about the 2.0 release proposal, what's
> the status of that?
Under discussion. Looks likely to happen in the next few months.
>
> 3) also, what's the status of the variuos stores? are they usable?
No. They all have either critical correctness or performance problems.
Work is happening to provide a usable JDBC-based store in the relatively
near future.
>
> 4) now a more detailed question: does the DASL implementation provided
> with Slide scale? are the content metadata stored in the DB or are
> stored along with the files?
The DASL implementation with the available stores is extremely
non-scalable. Content metadata is stored in the DB if you're using a
DB-based store, as are the file contents.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Random comments and bugfixes
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Sylvain Wallez wrote:
> Ermm... not that I will loose sleep, but what is a "baseplane"
> character????
A sloppy phrase :-)
The Unicode base plane covers the code points U+0000..U+FFFF,
i.e. characters which can be represented using a 16 bit value.
There are characters assigned to code points above 65536.
Check http://www.unicode.org for details.
J.Pietschmann
Re: Random comments and bugfixes
Posted by Sylvain Wallez <sy...@apache.org>.
J.Pietschmann wrote:
<snip/>
> I personally wouldn't loose much sleep over this particular problem.
> Unless you are into MathML or obscure historic scripts, non-baseplane
> characters are more of a curiosum.
Ermm... not that I will loose sleep, but what is a "baseplane" character????
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Random comments and bugfixes
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Stefano Mazzocchi wrote:
> ... 0xd800 is not a legal XML character.
...
> <high-unicode ...>𐀀</high-unicode>
>
> Now: whose problem is this Slide's or JDOM's?
JDOM, I'd guess without looking at the code. This is a very general
problem: The surrogate Unicode codepoints are illegal for itself in
XML, but of course in Java strings there is no way to express
non-baseplane characters other than as two surrogates. Problem:
if the test for illegal surrogates is before character reference
expansion, illegal surrogates may sneak in as char refs. If the test is
after character reference expansion, a non-baseplane character may
trigger a false positive. Obviously, the test has to be done twice,
once for literal characters and once as part of dealing with character
references.
I personally wouldn't loose much sleep over this particular problem.
Unless you are into MathML or obscure historic scripts, non-baseplane
characters are more of a curiosum.
J.Pietschmann
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>>
>>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>>
>>>> Just a note to let you know that there are a number of
>>>> threads currently running over on the dev@avalon.apache.org
>>>> concerning the establishment of a component repository
>>>> project. After reading your email I think that many of the
>>>> subjects you have addressed below are relevant to the things
>>>> the Avalon crew are currently debating.
>>>
>>>
>>>
>>> a content repository is a place where you store semi-structured
>>> data, you version it, you add metadata and you query it... it has to
>>> scale O(1) with the number of nodes (not even o(n), that's too much)
>>> and allow the smallest granularity possible (potentially, down to
>>> the very DOM node). Plusses are: granular ACL, node linking,
>>> transactionality, obvservability.
>>>
>>> a component repository is a library of java components, a sort of
>>> CPAN/PEAR/apt-get for java.
>>>
>>> Can you do a component repository with a content repository? yes, of
>>> course.
>>>
>>> Can you do a content repository with a component repository? no and
>>> would even be silly to try to do so.
>>
>>
>>
>> Just one more variation to complete the picture - a service directory.
>
>
> Oh god. [sound of stefano banging his head on the table]
Take an asprin!
>> A content repository can be viewed as a service.
>
>
> Stephen, everything can be viewed as a service. Escalating
> abstractions will not make it any easier for me to have the features I
> need, rather the opposite.
>
>> A directory can be used to discover a service provision solution
>> (using for example a repository of component descriptions).
>> Component descriptions can reference artifacts in an content
>> repository. A component implementation can also use a content
>> repository as part of its implementation. Etc., etc. In this respect
>> - the ideas of a content repository and component repository are
>> synergistic.
>
>
> As I said, a component repository can be built with a content
> repository. The opposite is simply not true.
Umm, did I suggest anywhere that it was true?
> My point is: there is no need for slide to look at what avalon is doing.
What I was originally responding to was the note from Edison Too
referencing a lack of certain services/components in Avalon - a subject
which is relevant to the threads over on Avalon concerning a component
repository. My response to you comments was simply agreeing with your
point concerning content/component and noting the respective synergies.
Cheers, Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>>
>>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>>
>>>> Just a note to let you know that there are a number of
>>>> threads currently running over on the dev@avalon.apache.org
>>>> concerning the establishment of a component repository
>>>> project. After reading your email I think that many of the
>>>> subjects you have addressed below are relevant to the things
>>>> the Avalon crew are currently debating.
>>>
>>>
>>>
>>> a content repository is a place where you store semi-structured
>>> data, you version it, you add metadata and you query it... it has to
>>> scale O(1) with the number of nodes (not even o(n), that's too much)
>>> and allow the smallest granularity possible (potentially, down to
>>> the very DOM node). Plusses are: granular ACL, node linking,
>>> transactionality, obvservability.
>>>
>>> a component repository is a library of java components, a sort of
>>> CPAN/PEAR/apt-get for java.
>>>
>>> Can you do a component repository with a content repository? yes, of
>>> course.
>>>
>>> Can you do a content repository with a component repository? no and
>>> would even be silly to try to do so.
>>
>>
>>
>> Just one more variation to complete the picture - a service directory.
>
>
> Oh god. [sound of stefano banging his head on the table]
Take an asprin!
>> A content repository can be viewed as a service.
>
>
> Stephen, everything can be viewed as a service. Escalating
> abstractions will not make it any easier for me to have the features I
> need, rather the opposite.
>
>> A directory can be used to discover a service provision solution
>> (using for example a repository of component descriptions).
>> Component descriptions can reference artifacts in an content
>> repository. A component implementation can also use a content
>> repository as part of its implementation. Etc., etc. In this respect
>> - the ideas of a content repository and component repository are
>> synergistic.
>
>
> As I said, a component repository can be built with a content
> repository. The opposite is simply not true.
Umm, did I suggest anywhere that it was true?
> My point is: there is no need for slide to look at what avalon is doing.
What I was originally responding to was the note from Edison Too
referencing a lack of certain services/components in Avalon - a subject
which is relevant to the threads over on Avalon concerning a component
repository. My response to you comments was simply agreeing with your
point concerning content/component and noting the respective synergies.
Cheers, Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>>
>>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>>
>>>> Just a note to let you know that there are a number of
>>>> threads currently running over on the dev@avalon.apache.org
>>>> concerning the establishment of a component repository
>>>> project. After reading your email I think that many of the
>>>> subjects you have addressed below are relevant to the things
>>>> the Avalon crew are currently debating.
>>>
>>>
>>>
>>> a content repository is a place where you store semi-structured
>>> data, you version it, you add metadata and you query it... it has to
>>> scale O(1) with the number of nodes (not even o(n), that's too much)
>>> and allow the smallest granularity possible (potentially, down to
>>> the very DOM node). Plusses are: granular ACL, node linking,
>>> transactionality, obvservability.
>>>
>>> a component repository is a library of java components, a sort of
>>> CPAN/PEAR/apt-get for java.
>>>
>>> Can you do a component repository with a content repository? yes, of
>>> course.
>>>
>>> Can you do a content repository with a component repository? no and
>>> would even be silly to try to do so.
>>
>>
>>
>> Just one more variation to complete the picture - a service directory.
>
>
> Oh god. [sound of stefano banging his head on the table]
Take an asprin!
>> A content repository can be viewed as a service.
>
>
> Stephen, everything can be viewed as a service. Escalating
> abstractions will not make it any easier for me to have the features I
> need, rather the opposite.
>
>> A directory can be used to discover a service provision solution
>> (using for example a repository of component descriptions).
>> Component descriptions can reference artifacts in an content
>> repository. A component implementation can also use a content
>> repository as part of its implementation. Etc., etc. In this respect
>> - the ideas of a content repository and component repository are
>> synergistic.
>
>
> As I said, a component repository can be built with a content
> repository. The opposite is simply not true.
Umm, did I suggest anywhere that it was true?
> My point is: there is no need for slide to look at what avalon is doing.
What I was originally responding to was the note from Edison Too
referencing a lack of certain services/components in Avalon - a subject
which is relevant to the threads over on Avalon concerning a component
repository. My response to you comments was simply agreeing with your
point concerning content/component and noting the respective synergies.
Cheers, Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>
> Stefano Mazzocchi wrote:
>
>>
>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>
>>> Just a note to let you know that there are a number of
>>> threads currently running over on the dev@avalon.apache.org
>>> concerning the establishment of a component repository
>>> project. After reading your email I think that many of the
>>> subjects you have addressed below are relevant to the things
>>> the Avalon crew are currently debating.
>>
>>
>> a content repository is a place where you store semi-structured data,
>> you version it, you add metadata and you query it... it has to scale
>> O(1) with the number of nodes (not even o(n), that's too much) and
>> allow the smallest granularity possible (potentially, down to the
>> very DOM node). Plusses are: granular ACL, node linking,
>> transactionality, obvservability.
>>
>> a component repository is a library of java components, a sort of
>> CPAN/PEAR/apt-get for java.
>>
>> Can you do a component repository with a content repository? yes, of
>> course.
>>
>> Can you do a content repository with a component repository? no and
>> would even be silly to try to do so.
>
>
> Just one more variation to complete the picture - a service directory.
Oh god. [sound of stefano banging his head on the table]
> A content repository can be viewed as a service.
Stephen, everything can be viewed as a service. Escalating abstractions
will not make it any easier for me to have the features I need, rather
the opposite.
> A directory can be used to discover a service provision solution
> (using for example a repository of component descriptions). Component
> descriptions can reference artifacts in an content repository. A
> component implementation can also use a content repository as part of
> its implementation. Etc., etc. In this respect - the ideas of a
> content repository and component repository are synergistic.
As I said, a component repository can be built with a content
repository. The opposite is simply not true.
My point is: there is no need for slide to look at what avalon is
doing. The opposite might be true, but I think that using a content
repository for a component repository is simply overkill. A nice and
simple web server and a few servlets for lookup/discovery would do the
job just fine.
--
Stefano.
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>
> Stefano Mazzocchi wrote:
>
>>
>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>
>>> Just a note to let you know that there are a number of
>>> threads currently running over on the dev@avalon.apache.org
>>> concerning the establishment of a component repository
>>> project. After reading your email I think that many of the
>>> subjects you have addressed below are relevant to the things
>>> the Avalon crew are currently debating.
>>
>>
>> a content repository is a place where you store semi-structured data,
>> you version it, you add metadata and you query it... it has to scale
>> O(1) with the number of nodes (not even o(n), that's too much) and
>> allow the smallest granularity possible (potentially, down to the
>> very DOM node). Plusses are: granular ACL, node linking,
>> transactionality, obvservability.
>>
>> a component repository is a library of java components, a sort of
>> CPAN/PEAR/apt-get for java.
>>
>> Can you do a component repository with a content repository? yes, of
>> course.
>>
>> Can you do a content repository with a component repository? no and
>> would even be silly to try to do so.
>
>
> Just one more variation to complete the picture - a service directory.
Oh god. [sound of stefano banging his head on the table]
> A content repository can be viewed as a service.
Stephen, everything can be viewed as a service. Escalating abstractions
will not make it any easier for me to have the features I need, rather
the opposite.
> A directory can be used to discover a service provision solution
> (using for example a repository of component descriptions). Component
> descriptions can reference artifacts in an content repository. A
> component implementation can also use a content repository as part of
> its implementation. Etc., etc. In this respect - the ideas of a
> content repository and component repository are synergistic.
As I said, a component repository can be built with a content
repository. The opposite is simply not true.
My point is: there is no need for slide to look at what avalon is
doing. The opposite might be true, but I think that using a content
repository for a component repository is simply overkill. A nice and
simple web server and a few servlets for lookup/discovery would do the
job just fine.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
>
>
> Stefano Mazzocchi wrote:
>
>>
>> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>>
>>> Just a note to let you know that there are a number of
>>> threads currently running over on the dev@avalon.apache.org
>>> concerning the establishment of a component repository
>>> project. After reading your email I think that many of the
>>> subjects you have addressed below are relevant to the things
>>> the Avalon crew are currently debating.
>>
>>
>> a content repository is a place where you store semi-structured data,
>> you version it, you add metadata and you query it... it has to scale
>> O(1) with the number of nodes (not even o(n), that's too much) and
>> allow the smallest granularity possible (potentially, down to the
>> very DOM node). Plusses are: granular ACL, node linking,
>> transactionality, obvservability.
>>
>> a component repository is a library of java components, a sort of
>> CPAN/PEAR/apt-get for java.
>>
>> Can you do a component repository with a content repository? yes, of
>> course.
>>
>> Can you do a content repository with a component repository? no and
>> would even be silly to try to do so.
>
>
> Just one more variation to complete the picture - a service directory.
Oh god. [sound of stefano banging his head on the table]
> A content repository can be viewed as a service.
Stephen, everything can be viewed as a service. Escalating abstractions
will not make it any easier for me to have the features I need, rather
the opposite.
> A directory can be used to discover a service provision solution
> (using for example a repository of component descriptions). Component
> descriptions can reference artifacts in an content repository. A
> component implementation can also use a content repository as part of
> its implementation. Etc., etc. In this respect - the ideas of a
> content repository and component repository are synergistic.
As I said, a component repository can be built with a content
repository. The opposite is simply not true.
My point is: there is no need for slide to look at what avalon is
doing. The opposite might be true, but I think that using a content
repository for a component repository is simply overkill. A nice and
simple web server and a few servlets for lookup/discovery would do the
job just fine.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>
>> Just a note to let you know that there are a number of
>> threads currently running over on the dev@avalon.apache.org
>> concerning the establishment of a component repository
>> project. After reading your email I think that many of the
>> subjects you have addressed below are relevant to the things
>> the Avalon crew are currently debating.
>
>
> a content repository is a place where you store semi-structured data,
> you version it, you add metadata and you query it... it has to scale
> O(1) with the number of nodes (not even o(n), that's too much) and
> allow the smallest granularity possible (potentially, down to the very
> DOM node). Plusses are: granular ACL, node linking, transactionality,
> obvservability.
>
> a component repository is a library of java components, a sort of
> CPAN/PEAR/apt-get for java.
>
> Can you do a component repository with a content repository? yes, of
> course.
>
> Can you do a content repository with a component repository? no and
> would even be silly to try to do so.
Just one more variation to complete the picture - a service directory.
A content repository can be viewed as a service. A directory can be
used to discover a service provision solution (using for example a
repository of component descriptions). Component descriptions can
reference artifacts in an content repository. A component
implementation can also use a content repository as part of its
implementation. Etc., etc. In this respect - the ideas of a content
repository and component repository are synergistic.
Stephen.
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>
>> Just a note to let you know that there are a number of
>> threads currently running over on the dev@avalon.apache.org
>> concerning the establishment of a component repository
>> project. After reading your email I think that many of the
>> subjects you have addressed below are relevant to the things
>> the Avalon crew are currently debating.
>
>
> a content repository is a place where you store semi-structured data,
> you version it, you add metadata and you query it... it has to scale
> O(1) with the number of nodes (not even o(n), that's too much) and
> allow the smallest granularity possible (potentially, down to the very
> DOM node). Plusses are: granular ACL, node linking, transactionality,
> obvservability.
>
> a component repository is a library of java components, a sort of
> CPAN/PEAR/apt-get for java.
>
> Can you do a component repository with a content repository? yes, of
> course.
>
> Can you do a content repository with a component repository? no and
> would even be silly to try to do so.
Just one more variation to complete the picture - a service directory.
A content repository can be viewed as a service. A directory can be
used to discover a service provision solution (using for example a
repository of component descriptions). Component descriptions can
reference artifacts in an content repository. A component
implementation can also use a content repository as part of its
implementation. Etc., etc. In this respect - the ideas of a content
repository and component repository are synergistic.
Stephen.
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
>
>> Just a note to let you know that there are a number of
>> threads currently running over on the dev@avalon.apache.org
>> concerning the establishment of a component repository
>> project. After reading your email I think that many of the
>> subjects you have addressed below are relevant to the things
>> the Avalon crew are currently debating.
>
>
> a content repository is a place where you store semi-structured data,
> you version it, you add metadata and you query it... it has to scale
> O(1) with the number of nodes (not even o(n), that's too much) and
> allow the smallest granularity possible (potentially, down to the very
> DOM node). Plusses are: granular ACL, node linking, transactionality,
> obvservability.
>
> a component repository is a library of java components, a sort of
> CPAN/PEAR/apt-get for java.
>
> Can you do a component repository with a content repository? yes, of
> course.
>
> Can you do a content repository with a component repository? no and
> would even be silly to try to do so.
Just one more variation to complete the picture - a service directory.
A content repository can be viewed as a service. A directory can be
used to discover a service provision solution (using for example a
repository of component descriptions). Component descriptions can
reference artifacts in an content repository. A component
implementation can also use a content repository as part of its
implementation. Etc., etc. In this respect - the ideas of a content
repository and component repository are synergistic.
Stephen.
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
> Just a note to let you know that there are a number of
> threads currently running over on the dev@avalon.apache.org
> concerning the establishment of a component repository
> project. After reading your email I think that many of the
> subjects you have addressed below are relevant to the things
> the Avalon crew are currently debating.
a content repository is a place where you store semi-structured data,
you version it, you add metadata and you query it... it has to scale
O(1) with the number of nodes (not even o(n), that's too much) and
allow the smallest granularity possible (potentially, down to the very
DOM node). Plusses are: granular ACL, node linking, transactionality,
obvservability.
a component repository is a library of java components, a sort of
CPAN/PEAR/apt-get for java.
Can you do a component repository with a content repository? yes, of
course.
Can you do a content repository with a component repository? no and
would even be silly to try to do so.
--
Stefano
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
> Just a note to let you know that there are a number of
> threads currently running over on the dev@avalon.apache.org
> concerning the establishment of a component repository
> project. After reading your email I think that many of the
> subjects you have addressed below are relevant to the things
> the Avalon crew are currently debating.
a content repository is a place where you store semi-structured data,
you version it, you add metadata and you query it... it has to scale
O(1) with the number of nodes (not even o(n), that's too much) and
allow the smallest granularity possible (potentially, down to the very
DOM node). Plusses are: granular ACL, node linking, transactionality,
obvservability.
a component repository is a library of java components, a sort of
CPAN/PEAR/apt-get for java.
Can you do a component repository with a content repository? yes, of
course.
Can you do a content repository with a component repository? no and
would even be silly to try to do so.
--
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
> Just a note to let you know that there are a number of
> threads currently running over on the dev@avalon.apache.org
> concerning the establishment of a component repository
> project. After reading your email I think that many of the
> subjects you have addressed below are relevant to the things
> the Avalon crew are currently debating.
a content repository is a place where you store semi-structured data,
you version it, you add metadata and you query it... it has to scale
O(1) with the number of nodes (not even o(n), that's too much) and
allow the smallest granularity possible (potentially, down to the very
DOM node). Plusses are: granular ACL, node linking, transactionality,
obvservability.
a component repository is a library of java components, a sort of
CPAN/PEAR/apt-get for java.
Can you do a component repository with a content repository? yes, of
course.
Can you do a content repository with a component repository? no and
would even be silly to try to do so.
--
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Edison Too <ed...@yahoo.com.sg>.
Thanks, will check out the Avalon list.
Cheers,
Edison
On Wed, 12 Nov 2003 12:50:05 +0100, Stephen McConnell wrote:
>
>Just a note to let you know that there are a number of threads currently
>running over on the dev@avalon.apache.org concerning the establishment of a
>component repository project. After reading your email I think that many of
>the subjects you have addressed below are relevant to the things the Avalon
>crew are currently debating.
>
>Cheers, Steve.
>
>
>Edison Too wrote:
>
>>Hi,
>>
>>I agree with Stefano's observation that there is a need for a good content
>>repository. I've looked into Slide's code before and I can't help but wonder
>>if it is a good idea for Slide to be implemented using Avalon.
>>
>>The server core can be broken down into 3 blocks 1. Content repository
>>(store?) 2. User management 3. Access Control management These are very
>>useful/essential component which are (AFAIK) strangely missing in the current
>>crop of Avalon Components/Services.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Edison Too <ed...@yahoo.com.sg>.
Thanks, will check out the Avalon list.
Cheers,
Edison
On Wed, 12 Nov 2003 12:50:05 +0100, Stephen McConnell wrote:
>
>Just a note to let you know that there are a number of threads currently
>running over on the dev@avalon.apache.org concerning the establishment of a
>component repository project. After reading your email I think that many of
>the subjects you have addressed below are relevant to the things the Avalon
>crew are currently debating.
>
>Cheers, Steve.
>
>
>Edison Too wrote:
>
>>Hi,
>>
>>I agree with Stefano's observation that there is a need for a good content
>>repository. I've looked into Slide's code before and I can't help but wonder
>>if it is a good idea for Slide to be implemented using Avalon.
>>
>>The server core can be broken down into 3 blocks 1. Content repository
>>(store?) 2. User management 3. Access Control management These are very
>>useful/essential component which are (AFAIK) strangely missing in the current
>>crop of Avalon Components/Services.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Slide optimisations
Posted by Nick Reddel <ni...@findesign.org>.
Hi
I´m developing a client application based on webdav, using Slide as the
server, which is accessing large collections (in the thousands), and I'm
running into problems with the time Slide takes to execute a PROPFIND on
large collections .
One thing I noticed in the PROPFIND method is that ~30% of the total
method time is taken in the call to <getLabeledResourceUri> in
<VersioningHelper>, since the helper class retrieves all the node
descriptors (including their properties) from the store - so in fact the
revisions are retrieved from the store 2 or 3 times rather than once.
Anyway, the following patch on <VersioningHelper> improves the response
time of PROPFIND by 20-30%. The assumption is that the URI of the latest
version of a resource is the URI itself, in all cases (I think this is
true, from the code, and it works).
* $Header:
/home/cvspublic/jakarta-slide/src/webdav/server/org/apache/slide/webdav/
util/VersioningHelper.java,v 1.91 2003/10/16 10:51:24 pnever Exp $
* $Revision: 1.91 $
Original (lines 1933-1935)
public static String getLabeledResourceUri(NamespaceAccessToken
nsaToken, SlideToken sToken, Content content, String resourcePath,
String label) throws SlideException, LabeledRevisionNotFoundException {
NodeRevisionDescriptors revisionDescriptors =
content.retrieve( sToken, resourcePath );
Patched (1933-1938)
public static String getLabeledResourceUri(NamespaceAccessToken
nsaToken, SlideToken sToken, Content content, String resourcePath,
String label) throws SlideException, LabeledRevisionNotFoundException {
if (label == null){
return resourcePath;
}
NodeRevisionDescriptors revisionDescriptors =
content.retrieve( sToken, resourcePath );
Questions: is it worthwhile caring about optimisation yet, and is this
the proper forum for such a small patch, or should I address a Slide
developer directly?
Nick Reddel
mailto:nick@ella-associates.com
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Edison Too <ed...@yahoo.com.sg>.
Thanks, will check out the Avalon list.
Cheers,
Edison
On Wed, 12 Nov 2003 12:50:05 +0100, Stephen McConnell wrote:
>
>Just a note to let you know that there are a number of threads currently
>running over on the dev@avalon.apache.org concerning the establishment of a
>component repository project. After reading your email I think that many of
>the subjects you have addressed below are relevant to the things the Avalon
>crew are currently debating.
>
>Cheers, Steve.
>
>
>Edison Too wrote:
>
>>Hi,
>>
>>I agree with Stefano's observation that there is a need for a good content
>>repository. I've looked into Slide's code before and I can't help but wonder
>>if it is a good idea for Slide to be implemented using Avalon.
>>
>>The server core can be broken down into 3 blocks 1. Content repository
>>(store?) 2. User management 3. Access Control management These are very
>>useful/essential component which are (AFAIK) strangely missing in the current
>>crop of Avalon Components/Services.
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Just a note to let you know that there are a number of
threads currently running over on the dev@avalon.apache.org
concerning the establishment of a component repository
project. After reading your email I think that many of the
subjects you have addressed below are relevant to the things
the Avalon crew are currently debating.
Cheers, Steve.
Edison Too wrote:
>Hi,
>
>I agree with Stefano's observation that there is a need for a good content repository. I've looked into Slide's code before and I can't help but wonder if it is a good idea for Slide to be implemented using Avalon.
>
>The server core can be broken down into 3 blocks
>1. Content repository (store?)
>2. User management
>3. Access Control management
>These are very useful/essential component which are (AFAIK) strangely missing in the current crop of Avalon Components/Services.
>
>Advantage of migrating :
>1. Reuse of Avalon components such as configuration/connections/pooling/logging etc.
>2. Deployable as a standalone or servlet using Fortress or Phoenix.
>3. If a Cache block comes along (from Cocoon maybe?) it can be reused in Slide to improve performance.
>4. Attract more developers from the land of Avalon or Cocoon.
>I think it will open up a lot of possibilities. Think of it, with James, Slide, Cocoon, interesting server apps can be built.
>
>I know it's not easy to switch and most developers dread such a big change especially when r2.0 is in view. This is just a thought I feel worth discussing, especially when Stefano says he will investing his time into Slide.
>
>I'm not an expert with Avalon, but I'm willing to invest some time if this the direction Slide decide to pursue.
>
>Thoughts?
>
>Cheers,
>Edison Too
>
>On Tue, 11 Nov 2003 16:02:00 +0100, Stefano Mazzocchi wrote:
>
>
>>[copying dev@cocoon because many people are in search for a serious versioned
>>content repository these days]
>>
>>Hello everyone,
>>
>>I find myself in the need for a serious WebDAV/DeltaV/DASL content repository
>>and after having searched land and sea and having tried all possible
>>combinations out there [pure mod_dav, catacomb and subversion], I decided to
>>use invest my effort in Slide, also because of the familiarity with the java
>>language compared to mod_dav which isn't really friendly for me]
>>
>>
>>
><snip/>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Just a note to let you know that there are a number of
threads currently running over on the dev@avalon.apache.org
concerning the establishment of a component repository
project. After reading your email I think that many of the
subjects you have addressed below are relevant to the things
the Avalon crew are currently debating.
Cheers, Steve.
Edison Too wrote:
>Hi,
>
>I agree with Stefano's observation that there is a need for a good content repository. I've looked into Slide's code before and I can't help but wonder if it is a good idea for Slide to be implemented using Avalon.
>
>The server core can be broken down into 3 blocks
>1. Content repository (store?)
>2. User management
>3. Access Control management
>These are very useful/essential component which are (AFAIK) strangely missing in the current crop of Avalon Components/Services.
>
>Advantage of migrating :
>1. Reuse of Avalon components such as configuration/connections/pooling/logging etc.
>2. Deployable as a standalone or servlet using Fortress or Phoenix.
>3. If a Cache block comes along (from Cocoon maybe?) it can be reused in Slide to improve performance.
>4. Attract more developers from the land of Avalon or Cocoon.
>I think it will open up a lot of possibilities. Think of it, with James, Slide, Cocoon, interesting server apps can be built.
>
>I know it's not easy to switch and most developers dread such a big change especially when r2.0 is in view. This is just a thought I feel worth discussing, especially when Stefano says he will investing his time into Slide.
>
>I'm not an expert with Avalon, but I'm willing to invest some time if this the direction Slide decide to pursue.
>
>Thoughts?
>
>Cheers,
>Edison Too
>
>On Tue, 11 Nov 2003 16:02:00 +0100, Stefano Mazzocchi wrote:
>
>
>>[copying dev@cocoon because many people are in search for a serious versioned
>>content repository these days]
>>
>>Hello everyone,
>>
>>I find myself in the need for a serious WebDAV/DeltaV/DASL content repository
>>and after having searched land and sea and having tried all possible
>>combinations out there [pure mod_dav, catacomb and subversion], I decided to
>>use invest my effort in Slide, also because of the familiarity with the java
>>language compared to mod_dav which isn't really friendly for me]
>>
>>
>>
><snip/>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Migrating to Avalon. Thoughts?
Posted by Stephen McConnell <mc...@apache.org>.
Just a note to let you know that there are a number of
threads currently running over on the dev@avalon.apache.org
concerning the establishment of a component repository
project. After reading your email I think that many of the
subjects you have addressed below are relevant to the things
the Avalon crew are currently debating.
Cheers, Steve.
Edison Too wrote:
>Hi,
>
>I agree with Stefano's observation that there is a need for a good content repository. I've looked into Slide's code before and I can't help but wonder if it is a good idea for Slide to be implemented using Avalon.
>
>The server core can be broken down into 3 blocks
>1. Content repository (store?)
>2. User management
>3. Access Control management
>These are very useful/essential component which are (AFAIK) strangely missing in the current crop of Avalon Components/Services.
>
>Advantage of migrating :
>1. Reuse of Avalon components such as configuration/connections/pooling/logging etc.
>2. Deployable as a standalone or servlet using Fortress or Phoenix.
>3. If a Cache block comes along (from Cocoon maybe?) it can be reused in Slide to improve performance.
>4. Attract more developers from the land of Avalon or Cocoon.
>I think it will open up a lot of possibilities. Think of it, with James, Slide, Cocoon, interesting server apps can be built.
>
>I know it's not easy to switch and most developers dread such a big change especially when r2.0 is in view. This is just a thought I feel worth discussing, especially when Stefano says he will investing his time into Slide.
>
>I'm not an expert with Avalon, but I'm willing to invest some time if this the direction Slide decide to pursue.
>
>Thoughts?
>
>Cheers,
>Edison Too
>
>On Tue, 11 Nov 2003 16:02:00 +0100, Stefano Mazzocchi wrote:
>
>
>>[copying dev@cocoon because many people are in search for a serious versioned
>>content repository these days]
>>
>>Hello everyone,
>>
>>I find myself in the need for a serious WebDAV/DeltaV/DASL content repository
>>and after having searched land and sea and having tried all possible
>>combinations out there [pure mod_dav, catacomb and subversion], I decided to
>>use invest my effort in Slide, also because of the familiarity with the java
>>language compared to mod_dav which isn't really friendly for me]
>>
>>
>>
><snip/>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts? [was: Re: Random comments andbugfixes]
Posted by Kent Sølvsten Rasmussen <ke...@aarhusmail.dk>.
Definitely agree with Remy on this.
About a year ago, I examined Avalon quite a bit. The IOC part is very nice, but the framework is a bit too heavy IMO.
Maybe Spring or PicoContainer would be worth examining instead.
If Slide2.0 is becoming close, it would be a bad idea to change too much now. I'd say do a beta or RC1 as soon as possible, remove the bugs, and then create the official release.
Then it could be a time for considering using another framework (Avalon, Spring, Pico).
Actually I thought that this project was more or less dead, good to proven wrong.
Anyway I can help?
Kent
Remy Maucherat <re...@apache.org> wrote:
> Edison Too wrote:
> > Hi,
> >
> > I agree with Stefano's observation that there is a need
> for a good
> > content repository. I've looked into Slide's code before
> and I can't
> > help but wonder if it is a good idea for Slide to be
> implemented
> > using Avalon.
> >
> > The server core can be broken down into 3 blocks 1.
> Content
> > repository (store?) 2. User management 3. Access Control
> management
> > These are very useful/essential component which are
> (AFAIK) strangely
> > missing in the current crop of Avalon
> Components/Services.
> >
> > Advantage of migrating : 1. Reuse of Avalon components
> such as
> > configuration/connections/pooling/logging etc. 2.
> Deployable as a
> > standalone or servlet using Fortress or Phoenix. 3. If a
> Cache block
> > comes along (from Cocoon maybe?) it can be reused in Slide
> to improve
> > performance. 4. Attract more developers from the land of
> Avalon or
> > Cocoon. I think it will open up a lot of possibilities.
> Think of it,
> > with James, Slide, Cocoon, interesting server apps can be
> built.
> >
> > I know it's not easy to switch and most developers dread
> such a big
> > change especially when r2.0 is in view. This is just a
> thought I feel
> > worth discussing, especially when Stefano says he will
> investing his
> > time into Slide.
> >
> > I'm not an expert with Avalon, but I'm willing to invest
> some time if
> > this the direction Slide decide to pursue.
> >
> > Thoughts?
>
> If I was still involved in this project, the answer would
> be: of course not.
> Avalon provides a set of utility components which all seem
> inferior to
> what is available in the commons without any strings
> attached, and as a
> result, I've been very careful to avoid using it.
> As for deployment of "blocks" or "services" (if you really
> need it in
> this case), a JMX based model (using commons-modeler 1.1, of
> course) is
> immensely more flexible, introduces almost zero coupling in
> the
> application, and is standards based.
>
> Of course, Slide committers are free to decide to do
> whatever they want :)
>
> Rémy
>
>
>
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts? [was: Re: Random comments and bugfixes]
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 13:58, Edison Too wrote:
> On Wed, 12 Nov 2003 10:19:57 +0100, Remy Maucherat wrote:
>> If I was still involved in this project, the answer would be: of
>> course not.
>> Avalon provides a set of utility components which all seem inferior
>> to what is
>> available in the commons without any strings attached, and as a
>> result, I've
>> been very careful to avoid using it. As for deployment of "blocks" or
>> "services" (if you really need it in this case), a JMX based model
>> (using
>> commons-modeler 1.1, of course) is immensely more flexible,
>> introduces almost
>> zero coupling in the application, and is standards based.
>>
>> Of course, Slide committers are free to decide to do whatever they
>> want :)
>>
>> Rémy
>
> Hi,
>
> I agree there exist many commons component that mirrors those
> excalibur components, I was at first bewildered at their similarity.
> However, who knows, Avalon may move towards using Commons packages as
> well. In fact, IIUC packaging Slide's functionality in Avalon's
> Framework interface does not mandate using of Avalon's component. The
> commons packages can still be used.
>
> After thinking it through, I realise that as a WebDAV project, Slide
> is working very well and since WebDAV extends the HTTP protocol,
> servlet is the smart way to go. In other words, Slide does not benefit
> much from a move to Avalon.
Yep.
> However I'm thinking of the amount of work already put into the core
> of Slide. Making it support Avalon potentially opens up the value
> hidden in the project. They could be useful components outside the
> context of a WebDAV server. I'm thinking of developers who may not be
> interested in Slide as a CMS but may be interested in using the
> Token-based access mechanism, or caching mechanism etc. I.e. the
> Avalon/Cocoon community will probably benefit from such a move.
This is the kind of thinking that bites you back. Open source doesn't
work like that, period. You don't componentize because "others might
want it". You want it and so you componentize, then send the patches.
If nobody does is because nobody cares and nobody would use those
components.
I call this darwinistic filtering.
> Putting it simply, moving the codebase to Avalon may interest more
> developers to contribute, resulting in more ideas, better testing etc.
> I guess that is the fabled/infamous project cross-pollination. Of
> course the surface, Slide does not gain much, while Avalon/Cocoon
> gains more.
Let me be crystal clear about this: I DISAGREE!
Slide is perfect where it is. Now, let's try to get it working to a
point where it's actually useful, not just a proof of concept.
--
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts? [was: Re: Random comments and bugfixes]
Posted by Edison Too <ed...@yahoo.com.sg>.
On Wed, 12 Nov 2003 10:19:57 +0100, Remy Maucherat wrote:
>Edison Too wrote:
>>Hi,
>>
>>I agree with Stefano's observation that there is a need for a good content
>>repository. I've looked into Slide's code before and I can't help but wonder
>>if it is a good idea for Slide to be implemented using Avalon.
>>
>>
<Snip/>
>>Thoughts?
>
>If I was still involved in this project, the answer would be: of course not.
>Avalon provides a set of utility components which all seem inferior to what is
>available in the commons without any strings attached, and as a result, I've
>been very careful to avoid using it. As for deployment of "blocks" or
>"services" (if you really need it in this case), a JMX based model (using
>commons-modeler 1.1, of course) is immensely more flexible, introduces almost
>zero coupling in the application, and is standards based.
>
>Of course, Slide committers are free to decide to do whatever they want :)
>
>Rémy
Hi,
I agree there exist many commons component that mirrors those excalibur components, I was at first bewildered at their similarity. However, who knows, Avalon may move towards using Commons packages as well. In fact, IIUC packaging Slide's functionality in Avalon's Framework interface does not mandate using of Avalon's component. The commons packages can still be used.
After thinking it through, I realise that as a WebDAV project, Slide is working very well and since WebDAV extends the HTTP protocol, servlet is the smart way to go. In other words, Slide does not benefit much from a move to Avalon.
However I'm thinking of the amount of work already put into the core of Slide. Making it support Avalon potentially opens up the value hidden in the project. They could be useful components outside the context of a WebDAV server. I'm thinking of developers who may not be interested in Slide as a CMS but may be interested in using the Token-based access mechanism, or caching mechanism etc. I.e. the Avalon/Cocoon community will probably benefit from such a move.
Putting it simply, moving the codebase to Avalon may interest more developers to contribute, resulting in more ideas, better testing etc. I guess that is the fabled/infamous project cross-pollination. Of course the surface, Slide does not gain much, while Avalon/Cocoon gains more.
Cheers,
Edison
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Migrating to Avalon. Thoughts? [was: Re: Random comments and
bugfixes]
Posted by Remy Maucherat <re...@apache.org>.
Edison Too wrote:
> Hi,
>
> I agree with Stefano's observation that there is a need for a good
> content repository. I've looked into Slide's code before and I can't
> help but wonder if it is a good idea for Slide to be implemented
> using Avalon.
>
> The server core can be broken down into 3 blocks 1. Content
> repository (store?) 2. User management 3. Access Control management
> These are very useful/essential component which are (AFAIK) strangely
> missing in the current crop of Avalon Components/Services.
>
> Advantage of migrating : 1. Reuse of Avalon components such as
> configuration/connections/pooling/logging etc. 2. Deployable as a
> standalone or servlet using Fortress or Phoenix. 3. If a Cache block
> comes along (from Cocoon maybe?) it can be reused in Slide to improve
> performance. 4. Attract more developers from the land of Avalon or
> Cocoon. I think it will open up a lot of possibilities. Think of it,
> with James, Slide, Cocoon, interesting server apps can be built.
>
> I know it's not easy to switch and most developers dread such a big
> change especially when r2.0 is in view. This is just a thought I feel
> worth discussing, especially when Stefano says he will investing his
> time into Slide.
>
> I'm not an expert with Avalon, but I'm willing to invest some time if
> this the direction Slide decide to pursue.
>
> Thoughts?
If I was still involved in this project, the answer would be: of course not.
Avalon provides a set of utility components which all seem inferior to
what is available in the commons without any strings attached, and as a
result, I've been very careful to avoid using it.
As for deployment of "blocks" or "services" (if you really need it in
this case), a JMX based model (using commons-modeler 1.1, of course) is
immensely more flexible, introduces almost zero coupling in the
application, and is standards based.
Of course, Slide committers are free to decide to do whatever they want :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Migrating to Avalon. Thoughts? [was: Re: Random comments and bugfixes]
Posted by Edison Too <ed...@yahoo.com.sg>.
Hi,
I agree with Stefano's observation that there is a need for a good content repository. I've looked into Slide's code before and I can't help but wonder if it is a good idea for Slide to be implemented using Avalon.
The server core can be broken down into 3 blocks
1. Content repository (store?)
2. User management
3. Access Control management
These are very useful/essential component which are (AFAIK) strangely missing in the current crop of Avalon Components/Services.
Advantage of migrating :
1. Reuse of Avalon components such as configuration/connections/pooling/logging etc.
2. Deployable as a standalone or servlet using Fortress or Phoenix.
3. If a Cache block comes along (from Cocoon maybe?) it can be reused in Slide to improve performance.
4. Attract more developers from the land of Avalon or Cocoon.
I think it will open up a lot of possibilities. Think of it, with James, Slide, Cocoon, interesting server apps can be built.
I know it's not easy to switch and most developers dread such a big change especially when r2.0 is in view. This is just a thought I feel worth discussing, especially when Stefano says he will investing his time into Slide.
I'm not an expert with Avalon, but I'm willing to invest some time if this the direction Slide decide to pursue.
Thoughts?
Cheers,
Edison Too
On Tue, 11 Nov 2003 16:02:00 +0100, Stefano Mazzocchi wrote:
>[copying dev@cocoon because many people are in search for a serious versioned
>content repository these days]
>
>Hello everyone,
>
>I find myself in the need for a serious WebDAV/DeltaV/DASL content repository
>and after having searched land and sea and having tried all possible
>combinations out there [pure mod_dav, catacomb and subversion], I decided to
>use invest my effort in Slide, also because of the familiarity with the java
>language compared to mod_dav which isn't really friendly for me]
>
<snip/>
Migrating to Avalon. Thoughts? [was: Re: Random comments and bugfixes]
Posted by Edison Too <ed...@yahoo.com.sg>.
Hi,
I agree with Stefano's observation that there is a need for a good content repository. I've looked into Slide's code before and I can't help but wonder if it is a good idea for Slide to be implemented using Avalon.
The server core can be broken down into 3 blocks
1. Content repository (store?)
2. User management
3. Access Control management
These are very useful/essential component which are (AFAIK) strangely missing in the current crop of Avalon Components/Services.
Advantage of migrating :
1. Reuse of Avalon components such as configuration/connections/pooling/logging etc.
2. Deployable as a standalone or servlet using Fortress or Phoenix.
3. If a Cache block comes along (from Cocoon maybe?) it can be reused in Slide to improve performance.
4. Attract more developers from the land of Avalon or Cocoon.
I think it will open up a lot of possibilities. Think of it, with James, Slide, Cocoon, interesting server apps can be built.
I know it's not easy to switch and most developers dread such a big change especially when r2.0 is in view. This is just a thought I feel worth discussing, especially when Stefano says he will investing his time into Slide.
I'm not an expert with Avalon, but I'm willing to invest some time if this the direction Slide decide to pursue.
Thoughts?
Cheers,
Edison Too
On Tue, 11 Nov 2003 16:02:00 +0100, Stefano Mazzocchi wrote:
>[copying dev@cocoon because many people are in search for a serious versioned
>content repository these days]
>
>Hello everyone,
>
>I find myself in the need for a serious WebDAV/DeltaV/DASL content repository
>and after having searched land and sea and having tried all possible
>combinations out there [pure mod_dav, catacomb and subversion], I decided to
>use invest my effort in Slide, also because of the familiarity with the java
>language compared to mod_dav which isn't really friendly for me]
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org