Migrating to Avalon. Thoughts? [was: Re: Random comments and bugfixes]
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 [EMAIL PROTECTED] 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] >
Re: Random comments and bugfixes
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+..U+, 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
J.Pietschmann wrote:
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
Stefano Mazzocchi wrote: ... 0xd800 is not a legal XML character. ... 𐀀 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
Random comments and bugfixes
[copying [EMAIL PROTECTED] 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:1
User-Agent: litmus/0.9.4 neon/0.24.2
Connection: TE
TE: trailers
Content-Length: 185
X-Litmus: props: 16 (prophighunicode)
𐀀
[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 way 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.
