What you all are saying makes a lot of sense.
If I can add my two cents - from the perspective of one which uses it
embedded in a km system (which I sell as a product).
- why I choose jspWiki (long long time ago): _simplicity _and _java and
jsp (-> easily embedded)_
- what I do NOT need:
-- ldap (and alike) integration - comes almost free from container
authentication / sson
-- db vs file system .. file system is ok.
- what I would like to have
-- hooks easily configurable for major actions (eg save/change a page) -
I got them simply adding to jsp pages - works but burden
to keep aligned on new versions/revision
-- a minimalist skin (other than how many you want with all bell and
whistles) to easy custom adapting if needed
Last few things I would add to my wish list - I know there could be
much debate on the first and the last ones are a pain in the
ass - but both affect what from my point of view is a major point for a
wiki - end user edit usability:
- add a few things to core 'native' markup. Eg 5 levels of heading
instead of 3 (mapped to h1/h5). I know
this would be 'non standard' but at the very end no standard exist
(unless you decide to choose and stricty adhere to mediawiki one).
- make it easier to cut/paste to/from formatted html pages and/or
Microsoft word - or at least try to manage things so that
formatting cannot be broken or end up in a mess.
- have a converter from mediawiki markup
On 11/23/2016 3:42 AM, Paul Uszak wrote:
That's the word I was looking for, lightweight. And nimble. Thank you Col.
It's a primarily text based, single /multi user, content presentation
system based on the ubiquitous Java technology stack. Flat file storage
for simple maintenance and backup. There is ostensibly no competition in
this particular space. JSPWiki could excel.
It makes absolutely no sense to incorporate features from advanced wikis as
there is no hope of successful competition. The economies of scale and
available resources are against it. Respectfully, it is not going to
replace MediaWiki or WordPress. Leave them to their LDAPs and DB2
integration. Let them worry about persisting a fundamentally stateless
protocol whilst JSPWiki skirts around it. There must be an appropriate
quote from Tzu Sun. I just can't find it at the moment...
On 22 November 2016 at 14:05, Col Willis <col.wil...@gmail.com> wrote:
I agree with Paul, it makes perfect sense to see JSPWiki as a
lightweight/free alternative to something like Confluence.
Very similar to how Bugzilla is usually the *starter* bug management tool
before investing in something like JIRA
Get it showing on here!
https://www.google.co.uk/search?q=free+confluence+
alternative&gws_rd=cr&ei=Z080WPPmFciCgAbBr4XgDQ
On 22 November 2016 at 13:53, Paul Uszak <paul.us...@gmail.com> wrote:
You're kidding, right?
I've asked this previously but for the newest members, I'll ask again.
What is JSPWiki for? I know that this appears to be banging a drum, but
it
is unrealistic to expect large scale uptake of JSPWiki if you can’t
decide
what or who it’s for. Picking out and replicating minor features of
successful products seems to be without direction and ultimately
fruitless. Could we be honest with ourselves here? Why are we looking
at
features from solutions used by the US Navy, Boeing and Orange? Is it to
compete with them, or to continue a hobby?
There is a huuuge market opportunity for a simple very low bandwidth wiki
/website solution (I see the two as synonymous). The market space is
virtually uncontested in this area. There are numerous strengths that
JSPWiki has that could be leveraged to dominate in this role. Market
segmentation is key here. Try to provide a solution to a very specific
problem, and do it well. There are thousands of nerds (I use the term
playfully) who'd like a turnkey solution to hosting their own website
from
that old box under the table. They struggle with low bandwidth. There
are
organisations across the whole of the developing world wanting their own
websites with minimal bandwidth requirements to pass over the mobile
network. There is now probably more mobile (low bandwidth) coverage in
Africa than hard wired. Pick a market segment and make it your own.
That's the route to success. “Whatever you are, be a good one”
On the specifics of Metalsmith and as a user of JSPWiki, I vote no. Why
rip out the heart of what already kinda works, to replace it with a
static
meta data driven tool? Don’t forget that static web sites are just a fad
like the old thick /thin client-server debate. It’ll pass so just stick
with what you know. The technology is not the issue here. That’s just
simple code. The vision is the issue.
JSPWiki doesn’t have to copy. JSPWiki could lead.
On 21 November 2016 at 19:43, Dave Koelmeyer <
dave.koelme...@davekoelmeyer.co.nz> wrote:
Nuxeo is a major open source enterprise documentation management system
product. Their developer team recently migrated all documentation from
Confluence to a static site generator. While not related directly to
JSPWiki, the reasons why they switched are interesting, and it's not
every day one hears about a switch from the Microsoft Office of wikis:
https://www.nuxeo.com/blog/from-confluence-to-metalsmith-
a-migration-story-of-nuxeo-docs/
This could provide some insight into potential features for JSPWiki
down
the line.
Cheers,
Dave
--
Dave Koelmeyer
http://blog.davekoelmeyer.co.nz
GPG Key ID: 0x238BFF87
--
Col
