interwiki-discuss — General discussion of interwiki ideas

Re: [Interwiki] GITH Up (+12.50% with 8X Average Volume) already on Friday's closing-market News Release - ref. Leonardo Dean

[Manuela G. <Dis...@gm...>]

tantrum breathe
Up On the News - GITH Up (+12.50% with 8X Average Volume) already on Friday's closing-market News Release. rotunda.

Get GITH Quote Here. wormy.
http://money.cnn.com/quote/quote.html?symb=GITH

Friday's Closing-Market News On GITH decrement.
Oracle, SQL Server and Sybase Can't All Be Wrong.  Staffing companies are the #1 employer in the USA today, and IT staffing with GITH is leading the revolution. lap.

NEW YORK, Oct. 20, 2006 (PRIMEZONE) -- GITH -- A recent report based on a survey of fourteen hundred Chief Information Officers predicts steady growth in Q4 for technology IT hiring. Thirty-four percent of CIOs surveyed plan to add IT staff and none anticipated cutbacks in personnel. mycology.

GITH sources personnel for companies and offers custom software solutions related to Oracle, SQL Server and Sybase and software such as SAP, JD Edwards, and PeopleSoft. The report done on behalf of Robert Half Technology specifically mentions that 71% of CIOs anticipated needing personnel having skill sets related to Oracle, SQL Server, and DB2. numb.

Read the entire news release from Friday Closing-Market deacon.
http://biz.yahoo.com/pz/061020/107201.html

GITH has been releasing steady news worldwide, from Yahoo Finance & Bloomberg to MSN & CNN Money, even the NASDAQ. Exposure for GITH is expansive.  The increased frequency of news leads us to believe that something big is coming for GITH. nosebag.

Oct. 17, 2006 (PRIMEZONE) -- Executive Job Market Report Forecasting 'War For Talent' Bolsters Comments by GITH President… blot.
http://news.moneycentral.msn.com/ticker/article.asp?Symbol=US:GITH&Feed=PZ&Date=20061017&ID=6111313

Oct. 14, 2006 (PRIMEZONE) -- GITH  Foresees Growth in Fourth Quarter... posts increase in sales revenue... myel.
http://www.bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GITH:US&sid=aMMgvBh5UWMA

Sept. 25, 2006 (PRIMEZONE) -- Market forces combining over the next few years to drive up demand for a decreasing supply of specialized IT personnel.  GITH is leading the 21st Century revolution... thicket.
http://www.nasdaq.com/aspxcontent/NewsStory.aspx?cpath=20060925\ACQPMZ200609251523PRIMZONEFULLFEED105738.htm&symbol=gith&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&selected=GITH&selecteddisplaysymbol=GITH&coname=GLOBAL%20IT&lo

regressive lapse this

[Interwiki] Re: [wiki-standards] interwiki-discuss --> wiki-standards?

[Dirk R. <di...@ri...>]

Sounds good to me. Thanks for taking the initiative!

Dirk

At 17.03.2006, Bayle Shanks wrote:
>Hello all,
>
>I thought I'd email everyone to make sure everyone is on the same page
>about merging these lists. The two lists are:
>
>http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards
>
>http://lists.sourceforge.net/lists/listinfo/interwiki-discuss
>
>In theory, these lists have separate topics; wiki-standards is
>presumably focused on wiki standards, while interwiki-discuss is open
>to broader discussion about anything "interwiki", standards or
>not; for example, talk about OneBigSoup, NearLinks, distributed wiki
>engines, and talk about particular wiki client applications (client editors,
>aggregators, synchronizers, cross-wiki bots, etc; although these don't
>seem to exist yet, aside from the excellent WikiMinion).
>
>In practice, both are low-traffic, and much of the interwiki-discuss
>traffic was about standards.
>
>So, as long as the members of wiki-standards are okay with the
>occasional discussion about one of the "broader" topics above (speak
>now or forever hold your peace!), I think interwiki-discuss should be
>disbanded and everyone should move to wiki-standards.
>
>(I think I am merely voicing what most people already did awhile
>ago, but I want to make sure everyone knows about and is happy with the merge)
>
>please speak now if you have any objections, thanks,
>   bayle
>
>_______________________________________________
>wiki-standards mailing list
>wik...@wi...
>http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards

[Interwiki] interwiki-discuss --> wiki-standards?

[Bayle S. <bs...@uc...>]

Hello all,

I thought I'd email everyone to make sure everyone is on the same page
about merging these lists. The two lists are:

http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards

http://lists.sourceforge.net/lists/listinfo/interwiki-discuss

In theory, these lists have separate topics; wiki-standards is
presumably focused on wiki standards, while interwiki-discuss is open
to broader discussion about anything "interwiki", standards or
not; for example, talk about OneBigSoup, NearLinks, distributed wiki
engines, and talk about particular wiki client applications (client editors,
aggregators, synchronizers, cross-wiki bots, etc; although these don't
seem to exist yet, aside from the excellent WikiMinion). 

In practice, both are low-traffic, and much of the interwiki-discuss
traffic was about standards.

So, as long as the members of wiki-standards are okay with the
occasional discussion about one of the "broader" topics above (speak
now or forever hold your peace!), I think interwiki-discuss should be
disbanded and everyone should move to wiki-standards.

(I think I am merely voicing what most people already did awhile
ago, but I want to make sure everyone knows about and is happy with the merge)

please speak now if you have any objections, thanks,
  bayle

[Interwiki] MetaWiki stack

[Sunir S. <su...@su...>]

Much thanks go to Bayle for organizing the InterWiki 
workshop at WikiSym. One item we agreed to move forward 
on is a 'MetaWiki stack.'

MetaWiki is the InterWiki search engine I wrote a long
time ago. However, it does not scale as it requires a lot
of manual attention. One way to alleviate that is by
building a more complete stack of technology.

Using Martin Cleaver's WikiCrawler to find wikis,

seeded by SwitchWiki's list of wikis,

we use Bayle Shank's WikiGateway to import data,

into Sunir Shah's MetaWiki,

which crawls for new wikis via the InterMap,

and then is used to support (facilitator):
    * SisterSites (John Abbe)
    * SwitchWiki (Mark Dilley)
    * SharedAntiSpam (Eugene Eric Kim)

Here are an initial three proposed standards I've put
on the table to make this easier

    http://usemod.com/cgi-bin/mb.pl?AllPages
    http://usemod.com/cgi-bin/mb.pl?InterMap#Standard
    http://usemod.com/cgi-bin/mb.pl?LinkDatabase

They are of course open to discussion, improvement, and
help in the Meatball way. I will be making MetaWiki
open source and providing access for others to add
new statistical processes to the engine.

The objectives of the stack are to provide some common
resource that will encourage communication amongst
wiki leaders. Right now there is no intrinsic reason
for us to talk to each other aside from spam.

That being recognized, using MetaWiki to discover and
assess more blacklist feeds into the pool will be a 
good motivator to get the ball rolling.

Best,
Sunir

[Interwiki] Reminder: interwiki workshop this tues

[Bayle S. <bs...@uc...>]

A reminder to everyone that the Interwiki Workshop (part of the Wiki
Symposium) is this Tuesday, Oct 18, 1:30pm-5:00pm (WikiSym is in San
Diego, USA).

If you're planning on attending, it would be nice if you'd put your
name on the workshop webpage, and put some notes about what you'd like
to discuss, so that we can plan.

http://wiki.wikisym.org/space/Interwiki+Workshop

Hope to see you there,
  bayle

Re: [Interwiki] use del.icio.us for SisterSites/NearLinks directory?

[Bayle S. <bs...@uc...>]

See also http://www.communitywiki.org/en/LocalLink



On Thu, Sep 29, 2005 at 04:42:14PM -0400, Bill Seitz wrote:
> Had a thought today....
> 
> I wonder whether we could use DelIcioUs to feed a SisterSites directory 
> instead of MeatBall:MetaWiki?
> 
> * A WikiEngine could have code to post all new pages to DelIcioUs 
> periodically.
> 
> * You could even use every WikiName mentioned in a page as a separate 
> tag to associate with that page.
> 
> Unfortunately, it doesn't look like you can limit your queries to a list 
> of hostnames (SocialNetworkContext).
> 
> * I wonder whether some combination of searching on tag-combos 
> ('tag1+tag2') (where each wiki space might use its own name as a tag) 
> and bundles might do the job?
> 
> http://webseitz.fluxent.com/wiki/z2005-09-30-DeliciousForSisterSites
> 
> thx
> Bill Seitz
> http://webseitz.fluxent.com/wiki
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Interwiki-discuss mailing list
> Int...@li...
> https://lists.sourceforge.net/lists/listinfo/interwiki-discuss
> 

RE: [Interwiki] use del.icio.us for SisterSites/NearLinks directory?

[Sunir S. <su...@su...>]

MetaWiki has been suffering due to focus on
anti-spam. The goal is to have it rebuilt
in the new year.

--ss


-----Original Message-----
From: int...@li...
[mailto:int...@li...] On Behalf
Of Bill Seitz
Sent: Thursday, September 29, 2005 4:42 PM
To: int...@li...
Subject: [Interwiki] use del.icio.us for SisterSites/NearLinks
directory?

Had a thought today....

I wonder whether we could use DelIcioUs to feed a SisterSites
directory 
instead of MeatBall:MetaWiki?

* A WikiEngine could have code to post all new pages to DelIcioUs

periodically.

* You could even use every WikiName mentioned in a page as a
separate 
tag to associate with that page.

Unfortunately, it doesn't look like you can limit your queries to
a list 
of hostnames (SocialNetworkContext).

* I wonder whether some combination of searching on tag-combos 
('tag1+tag2') (where each wiki space might use its own name as a
tag) 
and bundles might do the job?

http://webseitz.fluxent.com/wiki/z2005-09-30-DeliciousForSisterSi
tes

thx
Bill Seitz
http://webseitz.fluxent.com/wiki



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Interwiki-discuss mailing list
Int...@li...
https://lists.sourceforge.net/lists/listinfo/interwiki-discuss

[Interwiki] use del.icio.us for SisterSites/NearLinks directory?

[Bill S. <bi...@fl...>]

Had a thought today....

I wonder whether we could use DelIcioUs to feed a SisterSites directory 
instead of MeatBall:MetaWiki?

* A WikiEngine could have code to post all new pages to DelIcioUs 
periodically.

* You could even use every WikiName mentioned in a page as a separate 
tag to associate with that page.

Unfortunately, it doesn't look like you can limit your queries to a list 
of hostnames (SocialNetworkContext).

* I wonder whether some combination of searching on tag-combos 
('tag1+tag2') (where each wiki space might use its own name as a tag) 
and bundles might do the job?

http://webseitz.fluxent.com/wiki/z2005-09-30-DeliciousForSisterSites

thx
Bill Seitz
http://webseitz.fluxent.com/wiki

Re: [Interwiki] Fwd: Re: [expert] word to wiki format converter

[Bayle S. <bs...@uc...>]

i have a script that takes a directory of text files and uploads them
to a wiki. it should work with mediawiki.

but it doesn't do any formattting conversion at all. 

i know there are commandline programs like antiword that try to
convert MS word files to text. 

So one possible thing to do would be to use a shell script using
antiword to convert every file in the directory to text, and then use
my script to upload every text file. 

but the uploaded files would have no formatting.






On Thu, Sep 22, 2005 at 03:10:08PM -0400, Randy Kramer wrote:
> Over on the ex...@ma... list someone is asking about converting 
> MS Word and Apple Notebook files to (specifically) MediaWiki.  I thought 
> maybe there might be some suggestions over here.
> 
> If you have any, I'll pass them along.
> 
> Randy Kramer
> 
> ----------  Forwarded Message  ----------
> 
> Subject: Re: [expert] word to wiki format converter
> Date: Thursday 22 September 2005 02:22 pm
> From: "Jim C." <jli...@gm...>
> To: ex...@ma...
> 
> > Jim, I don't know MediaWiki, but TWiki can read html if it's not too
> > complicated.  Try exporting one document to html and see if MediaWiki can
> > handle it.
> 
> Well, ideally we would need a command line utility that could convert an
> entire directory all at once, even if we do need an intermediate file
> format.  I know there's probably a utility out there that will convert
> word to *.ps or *.pdf or even HTML but are there any utlities for
> converting any of these to something like *.wiki, or *.twiki or anything
> close?  If I need to convert between wiki formats, I can always use sed.
> 
> The real problem is going to be those Apple Notebook files which are
> *.nb  Apple Notebook comes with NO export capability. :-/
> 
> Jim C.
> 
> -------------------------------------------------------
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Interwiki-discuss mailing list
> Int...@li...
> https://lists.sourceforge.net/lists/listinfo/interwiki-discuss
> 

[Interwiki] Fwd: Re: [expert] word to wiki format converter

[Randy K. <rhk...@gm...>]

Over on the ex...@ma... list someone is asking about converting 
MS Word and Apple Notebook files to (specifically) MediaWiki.  I thought 
maybe there might be some suggestions over here.

If you have any, I'll pass them along.

Randy Kramer

----------  Forwarded Message  ----------

Subject: Re: [expert] word to wiki format converter
Date: Thursday 22 September 2005 02:22 pm
From: "Jim C." <jli...@gm...>
To: ex...@ma...

> Jim, I don't know MediaWiki, but TWiki can read html if it's not too
> complicated.  Try exporting one document to html and see if MediaWiki can
> handle it.

Well, ideally we would need a command line utility that could convert an
entire directory all at once, even if we do need an intermediate file
format.  I know there's probably a utility out there that will convert
word to *.ps or *.pdf or even HTML but are there any utlities for
converting any of these to something like *.wiki, or *.twiki or anything
close?  If I need to convert between wiki formats, I can always use sed.

The real problem is going to be those Apple Notebook files which are
*.nb  Apple Notebook comes with NO export capability. :-/

Jim C.

-------------------------------------------------------

RE: [Interwiki] webdav vs FTP

[Dennis E. H. <den...@ac...>]

Nice collection of Greg Stein's observations.

I had a slap-your-forehead-Dennis moment too, and this is a good post to add
it to.

The thing about WebDAV clients is they are quietly in a lot more places than
you think. jEdit has a WebDAV plug-in (don't know its status), there's DAV4J
from the folks at IBM, and I believe Eclipse must support WebDAV by now (it
was pending when I last looked too long ago).  There's at least one version
of emacs that has one.  There's a standalone version for testing against a
server too.  There's more at <http://www.webdav.org/projects/>.  

Also, Zwiki is apparently hosted on Zope, a WebDAV-Python-based server, so
there should be some more info there on how they integrate them, if they do.

OS X has a WebDAV extender tied to the file system, I'm told.  

It is definitely the case that Windows supports WebDAV and provides
suite-level client solutions.  The Network Places protocol supports WebDAV,
and you can get a trial account on a WebDAV server somewhere and see exactly
how it works. Internet Explorer will access a WebDAV site, though not sure
how well editing works. (My sharemation account seems to have imploded, so I
can't test anything this minute.)

(IIS and I believe SharePoint support WebDAV, even MSN Groups does, although
the IIS one may have been turned off as a default when there was an exploit
vulnerability against their WebDAV.)

Back to the client side: The Network Places can be WebDAV bindings (Windows
will remember the logon and reconnect just like for FTP or shared files).
Also, Microsoft Office applications will work WebDAV so you could actually
edit wikitext in MS Word if you wanted to. It looks like Notepad on Windows
XP will also do it (since it uses the same file-open and Save As ... common
dialogs, but I would check that more closely).  Microsoft FrontPage didn't
do WebDAV in the past, but it might now.  (Windows knows FrontPage
extensions of course, and if your server supports both, FrontPage extensions
will be chosen first, last time I checked.)  I should point out that FTP is
supported as well and as smoothly by the OS [;<).

With regard to authentication, there is a move afoot to make digest
authentication the absolute minimum and to make it clear that it is
required.  (My memory could be really defective about this.)  The IETF is
pretty strict about wanting more security in their protocols.  Remember,
though, this is for WebDAV access, not other access that a site mite
support, including the in-browser Wikitext editing that we all know and
love.  WebDAV is really a super-user/-administrator thing, and when used for
editable content-management applications, most people want some
authentication and authorization support.  (The WebDAV Authentication RFC is
pretty hairy, by the way, but it goes down to the resource level instead of
server-level.)


 - Dennis


-----Original Message-----
From: int...@li...
[mailto:int...@li...] On Behalf Of Bayle
Shanks
Sent: Wednesday, August 10, 2005 02:16
To: InterWiki list
Subject: [Interwiki] webdav vs FTP

> When Alex says that what he wants to do is
> 
> > I want to be able to grep and cat, find and touch and cp and mv, use 
> > Emacs or vi as I please, etc.  As far as I know, WebDAV is currently 
> > my better bet.
> 
> My question becomes, if we're talking about the server side, what is 
> it that is being sought that doesn't work with FTP and SSH, for 
> example?  This sounds a lot like (non-client) creation and 
> administrative function, and it is dealing with the server-side
information architecture, storage
> structures, etc.   That seems like WebDAV as HTTP-carried file-system
> access.  Well, OK, but what's the gain in terms of wikiness?

After I read Dennis's post, and after spending a few minutes getting over my
embarassment at not realizing myself that FTP can already do a lot of what I
want to use WebDav for (except versioning; but I can't do that with WebDav
yet either, I need WebDav+DeltaV), I decided to try and find out how WebDav
is different from FTP.

I put what I found on:

http://communitywiki.org/WebDavVsFtp

-- bayle


p.s. hey this page would be good for ProtocolsWiki...



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Interwiki-discuss mailing list
Int...@li...
https://lists.sourceforge.net/lists/listinfo/interwiki-discuss

[Interwiki] wikis using DeltaV?

[Bayle S. <bs...@uc...>]

one interesting thing to look at is wikis which use WebDav+DeltaV as
their backend storage system. 

Subversion uses part of DeltaV, so SubWiki is one example. 

There's an apache module thingee called Catacomb which does part of
DeltaV (although is that project dead?), are there any wikis using
Catacomb?

-- bayle

[Interwiki] webdav vs FTP

[Bayle S. <bs...@uc...>]

> When Alex says that what he wants to do is
> 
> > I want to be able to grep and cat, find and touch and cp and mv,
> > use Emacs or vi as I please, etc.  As far as I know, WebDAV is 
> > currently my better bet.
> 
> My question becomes, if we're talking about the server side, what is it that
> is being sought that doesn't work with FTP and SSH, for example?  This
> sounds a lot like (non-client) creation and administrative function, and it
> is dealing with the server-side information architecture, storage
> structures, etc.   That seems like WebDAV as HTTP-carried file-system
> access.  Well, OK, but what's the gain in terms of wikiness?

After I read Dennis's post, and after spending a few minutes getting
over my embarassment at not realizing myself that FTP can already do
a lot of what I want to use WebDav for (except versioning; but I can't
do that with WebDav yet either, I need WebDav+DeltaV), I decided to
try and find out how WebDav is different from FTP.

I put what I found on:

http://communitywiki.org/WebDavVsFtp

-- bayle


p.s. hey this page would be good for ProtocolsWiki...

[Interwiki] re: cadaver; unit testing

[Bayle S. <bs...@uc...>]

i think cadaver is what i used for
testing, too (either that or "dave", i get them confused). 

i never scripted a unit
test using it; but eventually i was planning to write one using the
testReadableWriteableCollection class that i use for testing the other
interfaces in WikiGateway (and for testing the Atom server in my Atom
server package). Maybe it would be useful for you. It is a Test::Unit class that tests
interfaces to collections of documents. To use it, you override the
methods {createTestPage, updateTestPage, readTestPage, getTestFeed,
getLink, deleteTestPage}. 

Perl superclass:

http://cvs.sourceforge.net/viewcvs.py/interwiki/wikigateway/tests/unittests/testReadableWriteableCollection.pm?view=markup

Perl leaf class:

http://cvs.sourceforge.net/viewcvs.py/interwiki/wikigateway/tests/unittests/testWikiGatewayOnInterwikiSoftware.pm?view=markup


Python superclass:

http://cvs.sourceforge.net/viewcvs.py/interwiki/wikigateway/tests/unittests/TestReadableWriteableCollection.py?rev=1.1&view=log


(see http://cvs.sourceforge.net/viewcvs.py/interwiki/wikigateway/tests/unittests/ for more)

i should document that sometime...



On Tue, Aug 09, 2005 at 06:08:41PM +0200, Alex Schroeder wrote:
> Bayle Shanks schrieb:
> > Which is why I am interested to see what Alex (once he's done) and
> > Janne will have to say about their experiences implementing WebDAV. We
> > need more first-hand evidence about how hard (or how easy) it is to do
> > this.
> 
> I think the most important common experience the two of us had was the
> realization how crappy most of the existing WebDAV clients are.  :(
> 
> It would really be nice if we were to choose a "reference
> implementation".  For beginners, I would suggest cadaver -- a command
> line WebDAV client that offers an FTP interface.  That means that 1. it
> should be good enough to demonstrate that the wiki can implement a
> filesystem and 2. we can script a unit test using cadaver.
> 
> My first goal is a class 1, non-locking, no ACL, no versions interface,
> and prove that it works with cadaver.
> 
> Alex.

Re: JSPs and JSPWiki (Was: [Interwiki] Web Dav)

[Murray A. <m.a...@op...>]

I'd actually forgot I did this, but was browsing on Danny Ayer's
site and found it again:

   InterWikiMarkupLanguage (IWML)
   A Common Interchange Syntax for Wiki
   http://www.altheim.com/specs/iwml/

...weird how the web works sometimes.

I could resurrect work on this if there is interest.

Murray

......................................................................
Murray Altheim                          http://www.altheim.com/murray/
Strategic and Services Development
The Open University Library
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

        believe that everything is for
        you until you discover
        that you are for it
                               "The Robin and the Worm" by Don Marquis.
                               http://www.altheim.com/lit/robnworm.html

Re: [Interwiki] Web Dav

[Alex S. <al...@em...>]

Bayle Shanks schrieb:
> Since I know you're into Emacs, I thought you should be warned
> :). Does anyone know how to turn off these temp files?

Emacs has lock files and backup files it creates.  That would have to be
 turned off, at least for the WebDAV directories.  I bet both lock files
and backup files were rejected by Oddmuse because the filenames are not
legal pagenames anymore.

(elisp)Magic File Names has some info to get hackers started; I myself
will look at it once the rest works...  :)

Plus Emacs has it's own webdav client which I haven't looked at, yet.

Alex.

Re: [Interwiki] Web Dav

[Alex S. <al...@em...>]

Bayle Shanks schrieb:
> Which is why I am interested to see what Alex (once he's done) and
> Janne will have to say about their experiences implementing WebDAV. We
> need more first-hand evidence about how hard (or how easy) it is to do
> this.

I think the most important common experience the two of us had was the
realization how crappy most of the existing WebDAV clients are.  :(

It would really be nice if we were to choose a "reference
implementation".  For beginners, I would suggest cadaver -- a command
line WebDAV client that offers an FTP interface.  That means that 1. it
should be good enough to demonstrate that the wiki can implement a
filesystem and 2. we can script a unit test using cadaver.

My first goal is a class 1, non-locking, no ACL, no versions interface,
and prove that it works with cadaver.

Alex.

RE: [Interwiki] Web Dav

[Dennis E. H. <den...@ac...>]

I am intrigued to see the variety of schemes that are supported by
WikiGateway, along with this exploration.  WikiMedia is one of my favorites
in terms of presentation controls and possible bliki
(blog+wiki+microcontent+...) foundation.

I can't offer anything around concrete experience other than to suggest
DeltaV may be tough and to wonder about the problems of abstraction clash
that may arise among WebDAV, Atom, etc.

When Alex says that what he wants to do is

> I want to be able to grep and cat, find and touch and cp and mv,
> use Emacs or vi as I please, etc.  As far as I know, WebDAV is 
> currently my better bet.

My question becomes, if we're talking about the server side, what is it that
is being sought that doesn't work with FTP and SSH, for example?  This
sounds a lot like (non-client) creation and administrative function, and it
is dealing with the server-side information architecture, storage
structures, etc.   That seems like WebDAV as HTTP-carried file-system
access.  Well, OK, but what's the gain in terms of wikiness?

[I'm beginning to sound to myself like one of those folks who doesn't
understand how a document management system is different than a database
system used to manage documents, when its about manifest/encapsulated
abstractions that have minimal leakage.]

I have some experiments that I want to try in this area, but they don't seem
to be any closer to the top of my job-jar stack than when I first observed
the InterWiki conversation, so I think I will shut up for now, again [;<).

 - Dennis

PS: One serious problem with WebDAV is its development prior to a clear
understanding of XML namespaces, and some cruft in the property and
extension model.  If Atom 1.0 allows embedding of content under other
schemas and namespaces than its own, which I assume it must somehow, I would
think the prospect of Interwiki-ness and some sort of content negotiation
under interchange might be easier to comprehend there. And I'm just
guessing.  [;<). 

-----Original Message-----
From: int...@li...
[mailto:int...@li...] On Behalf Of Bayle
Shanks
Sent: Sunday, August 07, 2005 02:47
To: InterWiki list
Subject: Re: [Interwiki] Web Dav

I am eager to hear about people's experiences implementing WebDAV and Atom.

I feel that WikiRPCInterface is the easiest interface for a wiki server
developer to add.

However, WikiRPCInterface is a wiki-specific protocol, and it's RPC, so
there is no interoperability with non-wiki-specific software. 

If you want general interoperability (and we do), then you want a general
standard, like WebDAV or Atom. 

I've asked for clarification about when to use Atom and when to use WebDAV
but it seems there is not a canonical answer:

http://www.intertwingly.net/wiki/pie/WebDav

(see also http://www.intertwingly.net/wiki/pie/WebDavVsAtom)


However, one answer was that Atom is more lightweight whereas WebDAV
supports more stuff (for example, locking).


My own feeling is that WebDAV may be the way to go. I am heavily influenced
by the possibility of someday moving to WebDAV+DeltaV (btw, Subversion
clients and servers sort of use WebDAV+DeltaV, and are planning to support
it more in the future; so we could partially interoperate with them if wiki
"repositories" also used
WebDAV+DeltaV). In other words, there is already a web-standard
protocol for doing what we want in an interoperable way, and it's
WebDAV+DeltaV. WikiRPCInterface is too wiki-specific, and Atom doesn't do
versioning.


However, I am worried that WebDAV(+DeltaV) will turn out to be too
heavyweight/difficult to implement, and that therefore few wiki
servers will implement it. But I don't have much experience
implementing WebDAV(+DeltaV) myself (like Alex, I was able to use a
library to do most of the WebDAV stuff for me when I used it in
WikiGateway).

On the other hand, perhaps the libraries are good enough that no one
will have problems with WebDAV.

Which is why I am interested to see what Alex (once he's done) and
Janne will have to say about their experiences implementing WebDAV. We
need more first-hand evidence about how hard (or how easy) it is to do
this.

-- bayle



On Thu, Aug 04, 2005 at 11:51:47PM +0200, Alex Schroeder wrote:
> Dennis E. Hamilton schrieb:
> > I was wondering if the Atom 1.0 API might fit better too, being closer
to an
> > application level for editing and posting content on a wiki.
> 
> Maybe -- but I don't want to implement an Atom client.  I want to be
> able to grep and cat, find and touch and cp and mv, use Emacs or vi as I
> please, etc.  As far as I know, WebDAV is currently my better bet.
> 
> Alex.
> 




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Interwiki-discuss mailing list
Int...@li...
https://lists.sourceforge.net/lists/listinfo/interwiki-discuss

JSPs and JSPWiki (Was: [Interwiki] Web Dav)

[Murray A. <m.a...@op...>]

Bayle Shanks wrote:
> On Tue, Aug 02, 2005 at 12:15:16PM +0200, Alex Schroeder wrote:
> 
>>I read on the announcements of Wikimania that Janne of JSPwiki has added
>>WebDAV support.
> 
> I'm not able to be at Wikimania, unfortunately, but I see that 
> Janne's slides are quite interesting and touch on many things that
> we've been discussing (for example, he's in favor of XHTML as the
> interwiki markup format). I expect many of you will enjoy his slides:
> 
> http://upload.wikimedia.org/wikibooks/en/d/d9/Wikimania05-JJ1-presentation.sxi

Bayle,

Thanks for the link to Janne's slides.

For the past month or so I've been digging pretty heavily into
JSPWiki, as it might be useful in an upcoming multi-wiki project
for the OU Library. I'm still new to JSPs but have been learning
how things work via the example code as well as JSPWiki, and have
written three or four plugins (mostly as experiments), such as an
XHTML wiki page validator. I've also written a few JSPWiki templates,
but they're still buggy enough (on IE) that I've not posted them yet.

Ceryle currently has several JSPWiki instances running off of its
embedded Jetty server, and I'm at a point with Ceryle that I may
begin releasing source code to collaborators, in particular, I'm
looking for someone to assist in the move away from Java source
that is directly part of Ceryle towards more JSP-based code. For
example, I'm currently working on code within Ceryle to provide
web access to Ceryle's internal Xindice XML database, as a front
end to a bibliographic database (among other things). It currently
runs, but it uses hardcoded XHTML and I'd really prefer the whole
thing as JSPs. I'm also looking at better integrated Ceryle with
JSPWiki. I have some ideas on using the internal Topic Map engine
to map the contents of the JSPWiki pages, etc.

Considering that Ceryle has quite a lot of utility functionality,
interwiki stuff might be relatively painless using it as an
application framework, and you know that I've also been an advocate
of using XHTML as an interwiki markup format, and am still willing
to provide an DTD support as necessary for that project -- I've
still got all the source materials for XHTML modularization lying
around.

But I'm slow enough working with JSPs that at this point having
someone with some experience with them come in would be most
welcome. If there's anyone on this list who is comfortable in
JSPs and is interested in collaborating, please contact me offlist.

    http://purl.org/ceryle/

Thanks,

Murray

......................................................................
Murray Altheim                          http://www.altheim.com/murray/
Strategic and Services Development
The Open University Library
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

        believe that everything is for
        you until you discover
        that you are for it
                               "The Robin and the Worm" by Don Marquis.
                               http://www.altheim.com/lit/robnworm.html

Re: [Interwiki] Web Dav

[Bayle S. <bs...@uc...>]

On Tue, Aug 02, 2005 at 12:15:16PM +0200, Alex Schroeder wrote:
> I read on the announcements of Wikimania that Janne of JSPwiki has added
> WebDAV support.

I'm not able to be at Wikimania, unfortunately, but I see that 
Janne's slides are quite interesting and touch on many things that
we've been discussing (for example, he's in favor of XHTML as the
interwiki markup format). I expect many of you will enjoy his slides:

http://upload.wikimedia.org/wikibooks/en/d/d9/Wikimania05-JJ1-presentation.sxi

-- bayle

Re: [Interwiki] Web Dav

[Bayle S. <bs...@uc...>]

I am eager to hear about people's experiences implementing WebDAV and
Atom.

I feel that WikiRPCInterface is the easiest interface for a
wiki server developer to add.

However, WikiRPCInterface is a wiki-specific protocol, and it's RPC,
so there is no interoperability with non-wiki-specific software. 

If you want general interoperability (and we do), then you want a
general standard, like WebDAV or Atom. 

I've asked for clarification about when to use Atom and when to use
WebDAV but it seems there is not a canonical answer:

http://www.intertwingly.net/wiki/pie/WebDav

(see also http://www.intertwingly.net/wiki/pie/WebDavVsAtom)


However, one answer was that Atom is more lightweight whereas WebDAV
supports more stuff (for example, locking).


My own feeling is that WebDAV may be the way to go. I am heavily
influenced by the possibility of someday moving to WebDAV+DeltaV (btw,
Subversion clients and servers sort of use WebDAV+DeltaV, and are
planning to support it more in the future; so we could partially
interoperate with them if wiki "repositories" also used
WebDAV+DeltaV). In other words, there is already a web-standard
protocol for doing what we want in an interoperable way, 
and it's WebDAV+DeltaV. WikiRPCInterface is
too wiki-specific, and Atom doesn't do versioning.


However, I am worried that WebDAV(+DeltaV) will turn out to be too
heavyweight/difficult to implement, and that therefore few wiki
servers will implement it. But I don't have much experience
implementing WebDAV(+DeltaV) myself (like Alex, I was able to use a
library to do most of the WebDAV stuff for me when I used it in
WikiGateway).

On the other hand, perhaps the libraries are good enough that no one
will have problems with WebDAV.

Which is why I am interested to see what Alex (once he's done) and
Janne will have to say about their experiences implementing WebDAV. We
need more first-hand evidence about how hard (or how easy) it is to do
this.

-- bayle



On Thu, Aug 04, 2005 at 11:51:47PM +0200, Alex Schroeder wrote:
> Dennis E. Hamilton schrieb:
> > I was wondering if the Atom 1.0 API might fit better too, being closer to an
> > application level for editing and posting content on a wiki.
> 
> Maybe -- but I don't want to implement an Atom client.  I want to be
> able to grep and cat, find and touch and cp and mv, use Emacs or vi as I
> please, etc.  As far as I know, WebDAV is currently my better bet.
> 
> Alex.
> 

[Interwiki] quick wikigateway update

[Bayle S. <bs...@uc...>]

Changes:

* MediaWiki support is in CVS.

* a primitive "wikicp" command for copying wiki pages (but no markup
translation yet!) was in the last
(April; .00196) released version.

* WebDAV support (for the client-side) was in the last released version


Summary:

So, currently, if you
have any of these wiki server types:

* OddMuse
* UseMod
* MoinMoin
* MediaWiki
* Or any WikiRPCInterface-supporting server

then a client can, via WikiGateway, read and write to the wiki using
any of the following methods:

* WikiRPCInterface
* Atom
* WebDAV
* Python module
* Perl module
* Command-line client

It's likely that support for 2 more wiki servers will be added in the
next couple of months (although if people want to help out maybe we
could do more)

-- bayle

Re: [Interwiki] Web Dav

[Bayle S. <bs...@uc...>]

Alex,

When I used WikiGateway to mount CommunityWiki as a filesystem, I ran
into a problem using Emacs. Emacs insisted on creating a temporary
file when I opened a page for editing, in the same directory as the
file being edited. I forgot what the filename was;
I think is was .#actual_file_name.

I think it kept reading or writing to the temp file as I was editing the
page. Because of the latency of the connection, this made editing
so slow as to be unworkable. I don't remember if the remote wiki
accepted the weirdly-named file as a new page or if it kept rejecting
it but Emacs kept trying again. I couldn't find a way to turn off the
temp file, or even any mention of it in the emacs documentation. Since
networked filesystems have been around for awhile, I figure someone
would have run into this before, but I couldn't find the solution.

So I ended up using JEdit instead of Emacs, which worked.

Since I know you're into Emacs, I thought you should be warned
:). Does anyone know how to turn off these temp files?

-- bayle



On Thu, Aug 04, 2005 at 11:51:47PM +0200, Alex Schroeder wrote:
> Dennis E. Hamilton schrieb:
> > I was wondering if the Atom 1.0 API might fit better too, being closer to an
> > application level for editing and posting content on a wiki.
> 
> Maybe -- but I don't want to implement an Atom client.  I want to be
> able to grep and cat, find and touch and cp and mv, use Emacs or vi as I
> please, etc.  As far as I know, WebDAV is currently my better bet.
> 
> Alex.
> 

Re: [Interwiki] Web Dav

[Alex S. <al...@em...>]

Dennis E. Hamilton schrieb:
> I was wondering if the Atom 1.0 API might fit better too, being closer to an
> application level for editing and posting content on a wiki.

Maybe -- but I don't want to implement an Atom client.  I want to be
able to grep and cat, find and touch and cp and mv, use Emacs or vi as I
please, etc.  As far as I know, WebDAV is currently my better bet.

Alex.

RE: [Interwiki] Web Dav

[Dennis E. H. <den...@ac...>]

I was wondering if the Atom 1.0 API might fit better too, being closer to an
application level for editing and posting content on a wiki.

 - Dennis

-----Original Message-----
From: int...@li...
[mailto:int...@li...] On Behalf Of Alex
Schroeder
Sent: Thursday, August 04, 2005 05:08
To: den...@ac...
Cc: int...@li...
Subject: Re: [Interwiki] Web Dav

My current approach is to implement a virtual filesystem for my wiki as a
Perl module -- Filesys::Virtual::Oddmuse, and plug that into the
NET::DAV::Server Perl module.  At the moment that seems simple than to deal
with DAV directly.  It also limits my options for later, since I cannot
support versioning and all that -- but then again, the main benefit I see
for WebDAV integration is mounting the wiki as a filesystem.  So I hope it
be good enough.

I'm not even sure the MIME type issue comes up if I take the road via a
filesystem...  That would be a bonus, too, haha.

Alex.

Dennis E. Hamilton schrieb:
> You need to look at the WebDAV sites, especially
> 
> http://www.webdav.org/
> 
>  
> There is an effort to advance WebDAV up the standards track one notch 
> (2518 bis is the working draft), and you can find the status of all 
> proposals on http://greenbytes.de/tech/webdav/ along with any 
> information about errata, etc.
> 
[ ... ]