Hi Murray, ahh ok, now I see, so I guess we could start by making the reference manager pluggable through a wiki property, so anyone wishing to use it can do so easily.
Setting aside when to switch to JDK-11 (or whatever version we see fit), the graphmanager could be compiled with Java 11, having the rest of the project compiling with Java 8. The markdown module has been in a similar situation in the past, where it has been compiling with Java 8, and the rest of the project with Java 6 or 7, so that shouldn't be a stopper.. As for the number of pages, jspwiki-wiki has almost 400 pages, but there are other wikis out there with higher number of pages; f.ex., https://encyclopaedia-wot.org has almost 4000 pages, https://www.ecyrd.com/ButtUgly/wiki has around 3200 and http://ldapwiki.com/ almost 16400 HTH, juan pablo On Tue, Jul 26, 2022 at 3:02 PM Murray Altheim <murra...@altheim.com> wrote: > > > 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 > >
