On 26/07/22 6:30 am, Juan Pablo Santos Rodríguez wrote:
Hi Murray!
nice to see you on the dev list again :-)
Yes, thanks, good to see you as well. Many years... .. .
lots of interesting points on your email, my POV on them:
- re. GraphReferenceManager: I fail to see how it works, would you mind
sharing a concrete example? it is not clear to me if it needs a syntax
change or not, or if the current syntax would be used for a different
meaning? Would making the reference manager more "pluggable-friendly"
(i.e., selecting the implementation through a property file instead of
using classmapping-extra.xml) something helpful for you? You also mention
some possibility of an unsynchronized set of links on
DeafultReferenceManager, would you mind ellaborating a bit on it? If it's
fixable, I'd like to address it, rather than dropping the de/serialization,
it helps with faster startups on large wikis.
The GraphReferenceManager wouldn't require any syntax changes at all,
it's entirely focused on altering how the links are captured and stored.
So there are four link types:
1. normal intra-wiki links, e.g., [PageName]
2. links to Attachments on the same wiki
3. links to external URLs
4. links to uncreated pages
5. interwiki links (currently I'm not attempting to support them)
Currently the DefaultReferenceManager maintains two maps, m_refersTo and
m_referredBy. These store the various links, and ignore the external
links and uncreated pages are obtained dynamically by iterating through
all the links.
But this storage of links doesn't in any way represent the actual
structure of the links on the wiki, which form a graph. So what I'm
suggesting is to actually store link types 1-4 (5 will come later) as an
actual graph structure.
The GraphReferenceManager begins by creating vertices for all the pages,
then adds edges (links) for all the links between pages, with external
URLs and uncreated links (targets) isntantiated as graph nodes. So if
multiple links connect to the same external target URL, or to the same
uncreated page, they'd connect to the same graph vertex (node).
If a page is created, the graph is queried for an uncreated link that
matches and that link is replaced by the actual (new) vertex/node.
One can traverse the graph in various ways, and it's possible to
traverse at a set depth, e.g., "I want all nodes that are within three
steps from this one" et cetera.
Part of my interest in developing this is that I've had experience in
the past with commercial link managers (such as the Arbortext suite of
tools), which typically store things in traditional databases, so the
graph storage is not native but synthetic. I've worked a fair bit with
Neo4j and thought that approaching a reference manager implementation
with a native graph database (or at least structure in-memory) would be
an interesting project.
I guess that raises the issue of what kind of scale (page count) do we
know of in the JSPWiki world? What's a reasonable high-end wiki page
count that my reference manager should be able to support easily? Rather
than serialising (using Java serialisation) the Maps, I'd more likely
use either a graph database or serialise to a proper graph syntax that's
natively supported by JGraphT. Reading an XML file from disk and
rebuilding the graph on modern hardware is pretty trivial nowadays.
- re. JGraphT, I've checked their repo and it's dual-licensed under EPL
2.0, so it could be brought as a dependency; maybe it would need a note on
the NOTICE file, but that should be all, I've to check that license on
detail to see what it requires to be used. However, that dependency
requires Java 11 to run, so as of today, on the convenience binaries, the
GraphReferenceManager and associated classes would not be shippable with
the main war. Which leds me to the next point
- re. Java 11: probably deserves an specific thread on itself, but right
now there aren't specific plans for it. Which does not mean we're not
tkaing that into account.. Given the pace of the JDK releases may be even
going to JDK-17 would seem reasonable, next Java LTS is due september 2023,
which is not that far. Maybe post-2.11.3 release seems like a good moment
to discuss this topic?
- re. Lombok, would be +1 from me
- re, plugins and graph reference manager package: if you plan to include
them on JSPWiki :-) then the org.apache.wiki package should be the way to
go, would be their final package in any case.
Yes, Java 11 is a requirement for JGraphT. And I'd probably recommend
the same for Lombok, i.e., I'd not want to drop back to a Java 8
compatible version. So yes, using the GraphReferenceManager would
require a Java 11 compatible environment. I'm doing most of my
development in Java 11 at this point. Java 8 actually has a longer EOL,
at 2030, but I'm not ready for the changes in anything post 11 at this
point, though I realise the Java version just keeps marching on... I'd
probably recommend Java 11 for JSPWiki though for the same reasons.
Going to Java 17+ starts to introduce a lot of things to the world of
Java that I'm not sure the project either benefits from or is compatible
with (such as the radical bump in JSP version).
So it sounds like my project could be a Java 11 external library for the
interim, and brought into the trunk sometime after a transition to Java 11+.
This doesn't shut down the project for me, just provides some insights
on how to align it best with what the JSPWiki team are doing.
Cheers,
Murray
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
