You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Juan Pablo Santos Rodríguez <ju...@gmail.com> on 2022/07/21 22:38:20 UTC
Incoming 2.11.3 vote+release
Hi!
Don't know for others, but I plan to do some minor dependency updates
throughout the weekend, having in mind starting a release vote next
Monday/Tuesday, if nothing steps in.
This release should fix a number of security issues, so every additional
testing that can be done in order to ensure a successful release will be
most welcome. If you encounter something not working as expected, please
shout out!
Best regards,
juan pablo
Re: GraphReferenceManager
Posted by Murray Altheim <mu...@altheim.com>.
On 2022/07/29 15:11, Juan Pablo Santos Rodríguez wrote:
> Hi Murray,
>
> Just a quick note, current wiki syntax allows a second | in order to
> support link attributes, e.g., [Page|MyPage|title='Page']. Markdown syntax
> allows the same thing using [](){}, IIRC, so perhaps
> [Subject|Predicate::Object] (or something like that) could be used instead?
Hi Juan Pablo,
Ah, thanks for the tip. If there's already a parser for an attribute, I
might choose to extend that with a 'predicate=' rather than extend the
parser itself. That way existing applications that don't now what to do
with the attribute will simply store it. The existing link attribute
syntax is probably better than my proposed syntax as it wouldn't break
any other wikis that weren't using the GraphReferenceManager (and any
sub-processors that handle the ontology-related stuff), i.e., the pages
would be still compatible regardless of ReferenceManager implementation.
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
Re: GraphReferenceManager
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi Murray,
Just a quick note, current wiki syntax allows a second | in order to
support link attributes, e.g., [Page|MyPage|title='Page']. Markdown syntax
allows the same thing using [](){}, IIRC, so perhaps
[Subject|Predicate::Object] (or something like that) could be used instead?
cheers,
juan pablo
El vie, 29 jul 2022 4:39, Murray Altheim <mu...@altheim.com> escribió:
> On 2022/07/29 6:01, Juan Pablo Santos Rodríguez wrote:
> > 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.
>
> Hi Juan Pablo,
>
> The one pseudo-proposal I'm considering adding to the syntax would be to
> support normal intra-wiki links, but also optionally permit a second
> vertical bar character '|' to create a triple/tuple, e.g.:
>
> [Subject|Predicate|Object]
>
> so that one could type a link to a page using another page. E.g.,
>
> [ThisPage|IsPreviousToPage|ThatPage]
> [ThatPage|HasPreviousPage|ThisPage]
> [ThisPage|HasParentPage|ThatPage]
> [ThisPage|HasCategory|ThatPage]
> [ErnestHemingway|IsA|Writer]
> [TheCat|SitsOn|TheMat]
>
> I did something similar back around 2005 with a wiki plugin that did
> exactly this, but with this proposal it'd be integrated as link syntax
> rather than as a plugin.
>
> This allows you to make a relationship between two pages (or a page and an
> external URL) that is typed by another page. That predicate page could in
> theory (in my system it always is) part of a predicate hierarchy. But I
> won't lead the team down that ontological rabbit hole. But for a teaser,
> one could create the predicates for first order predicate logic and begin
> to make statements between wiki pages (as "Terms) that describe what they
> mean. [This was part of the core of my unfinished Ph.D. work at that time.]
>
> So taking Cyc's definition of its 'genls' (inheritance) predicate:
>
> (isa genls TransitiveBinaryPredicate)
> (isa genls ReflexiveBinaryPredicate)
> (arg1Isa genls Collection)
> (arg2Isa genls Collection)
> (arg1Genl genls Thing)
> (arg2Genl genls Thing)
>
> one could express that as wiki pages with only minor syntactical changes:
>
> [IsA|Genls|TransitiveBinaryPredicate]
> [IsA|Genls|ReflexiveBinaryPredicate]
> [Arg1Isa|Genls|Collection]
> [Arg2Isa|Genls|Collection]
> [Arg1Genl|Genls|Thing]
> [Arg2Genl|Genls|Thing]
>
> But like I said, I won't go any further down that rabbit hole.
>
> > 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
>
> That probably shouldn't be an issue. I've got a test corpus of around 1200
> files that I could copy a few times to do a test at the 16K level and find
> out how long things take to process. I would be interested in knowing if
> there are any stats for that 16400 page wiki I could compare with... The
> ingest/accession (import/process metadata) on 1200 files with my digital
> library software is about 40 seconds, but that's also moving and writing
> files and creating an archive file for each. I might try to create a
> benchmark unit test to see how performance rates just for the reference
> manager.
>
> I'd still rather avoid Java serialisation/deserialisation if it turns out
> the difference between that and simply reading the source files isn't that
> huge. A lot cleaner design for sure. With high-frequence and multi-core
> CPUs, VMs and SSDs a lot of things that used to take a lot of time simply
> don't. I bought a 12 core, 24 thread i9 recently and my compile times
> (when coupled with command line optimisations) went from 90-120 seconds
> down to 15. For something like the reference manager where it's all reads
> and no writes (if we avoid serialisation on shutdown), then I think the
> performance even on 16K files should be reasonable. Interesting to test in
> any case.
>
> My time comes in spurts so I'm not sure how long this will take. I've
> currently got the bones of it, the easy bits, the rest is coming along...
>
> 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
>
>
Re: GraphReferenceManager
Posted by Murray Altheim <mu...@altheim.com>.
On 2022/07/29 6:01, Juan Pablo Santos Rodríguez wrote:
> 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.
Hi Juan Pablo,
The one pseudo-proposal I'm considering adding to the syntax would be to
support normal intra-wiki links, but also optionally permit a second
vertical bar character '|' to create a triple/tuple, e.g.:
[Subject|Predicate|Object]
so that one could type a link to a page using another page. E.g.,
[ThisPage|IsPreviousToPage|ThatPage]
[ThatPage|HasPreviousPage|ThisPage]
[ThisPage|HasParentPage|ThatPage]
[ThisPage|HasCategory|ThatPage]
[ErnestHemingway|IsA|Writer]
[TheCat|SitsOn|TheMat]
I did something similar back around 2005 with a wiki plugin that did
exactly this, but with this proposal it'd be integrated as link syntax
rather than as a plugin.
This allows you to make a relationship between two pages (or a page and an
external URL) that is typed by another page. That predicate page could in
theory (in my system it always is) part of a predicate hierarchy. But I
won't lead the team down that ontological rabbit hole. But for a teaser,
one could create the predicates for first order predicate logic and begin
to make statements between wiki pages (as "Terms) that describe what they
mean. [This was part of the core of my unfinished Ph.D. work at that time.]
So taking Cyc's definition of its 'genls' (inheritance) predicate:
(isa genls TransitiveBinaryPredicate)
(isa genls ReflexiveBinaryPredicate)
(arg1Isa genls Collection)
(arg2Isa genls Collection)
(arg1Genl genls Thing)
(arg2Genl genls Thing)
one could express that as wiki pages with only minor syntactical changes:
[IsA|Genls|TransitiveBinaryPredicate]
[IsA|Genls|ReflexiveBinaryPredicate]
[Arg1Isa|Genls|Collection]
[Arg2Isa|Genls|Collection]
[Arg1Genl|Genls|Thing]
[Arg2Genl|Genls|Thing]
But like I said, I won't go any further down that rabbit hole.
> 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
That probably shouldn't be an issue. I've got a test corpus of around 1200
files that I could copy a few times to do a test at the 16K level and find
out how long things take to process. I would be interested in knowing if
there are any stats for that 16400 page wiki I could compare with... The
ingest/accession (import/process metadata) on 1200 files with my digital
library software is about 40 seconds, but that's also moving and writing
files and creating an archive file for each. I might try to create a
benchmark unit test to see how performance rates just for the reference
manager.
I'd still rather avoid Java serialisation/deserialisation if it turns out
the difference between that and simply reading the source files isn't that
huge. A lot cleaner design for sure. With high-frequence and multi-core
CPUs, VMs and SSDs a lot of things that used to take a lot of time simply
don't. I bought a 12 core, 24 thread i9 recently and my compile times
(when coupled with command line optimisations) went from 90-120 seconds
down to 15. For something like the reference manager where it's all reads
and no writes (if we avoid serialisation on shutdown), then I think the
performance even on 16K files should be reasonable. Interesting to test in
any case.
My time comes in spurts so I'm not sure how long this will take. I've
currently got the bones of it, the easy bits, the rest is coming along...
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
Re: GraphReferenceManager
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
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 <mu...@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
>
>
Re: GraphReferenceManager
Posted by Murray Altheim <mu...@altheim.com>.
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
Re: GraphReferenceManager
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi Murray!
nice to see you on the dev list again :-)
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.
- 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.
cheers,
juan pablo
On Fri, Jul 22, 2022 at 4:16 AM Murray Altheim <mu...@altheim.com> wrote:
> Hi,
>
> I've been busy on my own projects but under the neocortext.net domain I
> will possibly soon be releasing some open source code, mostly related to
> digital libraries and ontologies. But there is some JSPWiki related code
> as well, as I've been incorporating JSPWiki into some of this other work.
>
> I'm working on a potential replacement DefaultReferenceManager. My first
> iteration proved not different enough from the existing code to warrant
> the update; yes, it removed some of the strangeness (and eliminated the
> serialization/deserialization, which I didn't find useful and created the
> possibility of an unsynchronized set of links), but I didn't find it very
> elegant, mostly just a cleanup but no real innovation.
>
> So rather than using Sets or Maps, I thought a better and certainly more
> interesting approach would use JGraphT to implement a proper graph
> structure
> of links between Pages, Attachments, as well as external links. With some
> default predicates that could be expanded so that wiki links could take the
> form of subject-predicate-object, i.e., actual tuples. The implementation
> is
> called GraphReferenceManager.
>
> A link in this system could look like:
>
> [Object] # where 'Object' is the target page, the
> implicit 'Subject' being the page
> containing the link (typical existing link)
> [Predicate|Object] # where 'Predicate' expresses the meaning of
> the link. Such predicates are wiki pages,
> with the three existing links hardwired:
> inter-page, attachment, and external links
> [Subject|Predicate|Object] # frees the link from its parent page, so
> links could be expressed anywhere
>
> I wouldn't introduce any changes to the link parser at first, so this
> extended syntax is only a proposal, and the GraphReferenceManager doesn't
> conceptionally require the syntax changes, i.e., I'd use hardwired values
> for the predicates until such point as predicates were supported in wiki
> syntax.
>
> This work raises some questions:
>
> 1. would anyone have any issues with introducing JGraphT into the
> JSPWiki
> set of dependencies?
>
> 2. would anyone have any issues with introducing Lombok into the JSPWiki
> set of dependencies? I'd rather use factories and builders than
> constructors, and would also like to avoid explicit getters and
> setters. Something like a DSL might be nice.
>
> 3. at what point is it planned to bump JSPWiki from Java 8 to say,
> Java 11? For my day job I've been doing a fair bit of remediation
> work
> on legacy apps, bumping them *up* to Java 8. But the number of
> features I've grown accustomed to in Java 11 makes these features a
> bit painful to lose.
>
> 4. would the team prefer I develop the reference manager under the
> org.apache.wiki.* package or under my own (net.neocortext.wiki.*)?
>
> ----
>
> I've also got a couple of JSPWiki plugins, e.g., a QR code plugin, that
> are close to ready for usage/testing.
>
> Also my wiki TagManager and associated tag plugins (Tag, Tags, HasTagOf)
> have been in use now for I suppose over a decade now on various wikis, so
> perhaps the team might be interested in incorporating a tagging
> functionality into the Apache code, or I can release it under my own
> package name as I have in the past.
>
> Good to see JSPWiki still ticking along, with a new release coming up!
>
> 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
>
>
GraphReferenceManager
Posted by Murray Altheim <mu...@altheim.com>.
Hi,
I've been busy on my own projects but under the neocortext.net domain I
will possibly soon be releasing some open source code, mostly related to
digital libraries and ontologies. But there is some JSPWiki related code
as well, as I've been incorporating JSPWiki into some of this other work.
I'm working on a potential replacement DefaultReferenceManager. My first
iteration proved not different enough from the existing code to warrant
the update; yes, it removed some of the strangeness (and eliminated the
serialization/deserialization, which I didn't find useful and created the
possibility of an unsynchronized set of links), but I didn't find it very
elegant, mostly just a cleanup but no real innovation.
So rather than using Sets or Maps, I thought a better and certainly more
interesting approach would use JGraphT to implement a proper graph structure
of links between Pages, Attachments, as well as external links. With some
default predicates that could be expanded so that wiki links could take the
form of subject-predicate-object, i.e., actual tuples. The implementation is
called GraphReferenceManager.
A link in this system could look like:
[Object] # where 'Object' is the target page, the
implicit 'Subject' being the page
containing the link (typical existing link)
[Predicate|Object] # where 'Predicate' expresses the meaning of
the link. Such predicates are wiki pages,
with the three existing links hardwired:
inter-page, attachment, and external links
[Subject|Predicate|Object] # frees the link from its parent page, so
links could be expressed anywhere
I wouldn't introduce any changes to the link parser at first, so this
extended syntax is only a proposal, and the GraphReferenceManager doesn't
conceptionally require the syntax changes, i.e., I'd use hardwired values
for the predicates until such point as predicates were supported in wiki
syntax.
This work raises some questions:
1. would anyone have any issues with introducing JGraphT into the JSPWiki
set of dependencies?
2. would anyone have any issues with introducing Lombok into the JSPWiki
set of dependencies? I'd rather use factories and builders than
constructors, and would also like to avoid explicit getters and
setters. Something like a DSL might be nice.
3. at what point is it planned to bump JSPWiki from Java 8 to say,
Java 11? For my day job I've been doing a fair bit of remediation work
on legacy apps, bumping them *up* to Java 8. But the number of
features I've grown accustomed to in Java 11 makes these features a
bit painful to lose.
4. would the team prefer I develop the reference manager under the
org.apache.wiki.* package or under my own (net.neocortext.wiki.*)?
----
I've also got a couple of JSPWiki plugins, e.g., a QR code plugin, that
are close to ready for usage/testing.
Also my wiki TagManager and associated tag plugins (Tag, Tags, HasTagOf)
have been in use now for I suppose over a decade now on various wikis, so
perhaps the team might be interested in incorporating a tagging
functionality into the Apache code, or I can release it under my own
package name as I have in the past.
Good to see JSPWiki still ticking along, with a new release coming up!
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