phpwiki-talk

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

[Franck M. <fr...@so...>]

http://www1.ietf.org/mail-archive/ietf/Current/msg24012.html

It all started by this message, for info...

Reini Urban wrote:

> Feel free to add comments:
>   http://phpwiki.sourceforge.net/phpwiki/WikiRFC


-- 
Franck Martin
ICT Specialist
fr...@so...
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

[Franck M. <fr...@so...>]

Please read:
http://www.ietf.org/rfc/rfc2026.txt

It describes how an Internet Draft becomes eventually a standard, but it 
is a long winding road...

As the document below is misleading in many parts.

I will write some modifications (as per suggestions) in the current 
Internet Draft (it has not yet been submitted), but I'm happy it is 
generating a lot of Interest and reactions (sometime you need to shake 
the tree). Please be mindful that at one stage we will all have to 
modify our various wiki engines to be compliant with a base standard... 
But this is not for now...

I will take the first round of suggestions I got, then submit to the 
IETF as Internet Draft version 1 and we will all have now a reference to 
make something better.

Cheers

Reini Urban wrote:

> Feel free to add comments:
>   http://phpwiki.sourceforge.net/phpwiki/WikiRFC


-- 
Franck Martin
ICT Specialist
fr...@so...
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

[Franck M. <fr...@so...>]

Please note, that I have not yet submitted the syntax to IETF, but told 
them I was working on it and wanted to submit it.

Before even a submission is adopted it will go to many review processes. 
Submitting a draft means that the process is now starting and open for 
comments. It may take time to reach RFC Standard level. I thought that 
there was some wiki people on IETF, but it seems I'm the only one there, 
so I contact this group to share at least experience between two wiki 
syntaxes...

I'm adding some coments...

Cheers

Reini Urban wrote:

> Feel free to add comments:
>   http://phpwiki.sourceforge.net/phpwiki/WikiRFC


-- 
Franck Martin
ICT Specialist
fr...@so...
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

[Phpwiki-talk] WikiAuth Schema patch

[Electrawn <ele...@el...>]

I've attached some initial spreading of WikiUserNew. I am hoping Reini =
will
adopt it. Remove the word stub from the end of the file as SF doesn't =
allow
.zip

WikiUser Class is a container for a handler that calls WikiAuth object,
which does the Authentication and Storage of WikiUsers. Inspired by =
WikiDB.
Going this way would make implementing authentications schemes a bit =
easier
and cleaner. The "object-morphing" style that we have would be better =
served
by an external handler (Like all the stuff in main.php to determine =
which
user to create).

Also less of a headache to look at. :D

I also suggest updating the user structure to support uids. Makes =
handling
sessions easier.

Going this way would make a better interface for pnPhpWiki or any other
phpwiki as module since all we have to connect to is wikiauth.

Trying to figure out BOGO and if we really need it? That's a second =
headache
looking at the code. What is a bogo? Grr.

I'm trying to move pnPhpWiki out of alpha to a beta. With the new page
permissions and wikiuser.php seems broke against CVS. I am eagerly =
waiting
release 1.3.8 so I can snapshot against that code base and do =
experimental
stuff later.

I think we have a lot of shake out with WikiUser before a release, =
however.

-Jtp

[Phpwiki-talk] Error after installing. New with wikiwiki and php, please help

[Jorge H. <her...@ho...>]

I just contracted a hosting with onhost.ws and as an option you can install 
the wikiwiki, however, after doing that, I got the following error:


lib/WikiDB/backend/PearDB.php:32: Fatal[256]: Can't connect to database: 
wikidb_backend_mysql: fatal database error

DB Error: connect failed
( [nativecode=Access denied for user: 'visiongp_phpwiki1@localhost' (Using 
password: YES)] ** 
mysql://visiongp_phpwiki1:XXXXXXXX@localhost/visiongp_phpwiki1)


I've been looking for this problem but I had no luck. Unfortunatelly the 
hosting company does not provide any assistance to the matter.

I will appreciate if somebody can help me (for dummies) how to fix this 
problem.

Thank you for your time.

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

[Reini U. <ru...@x-...>]

Feel free to add comments:
   http://phpwiki.sourceforge.net/phpwiki/WikiRFC
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] SOAP methods?

[Reini U. <ru...@x-...>]

Looks like that PhpWIki is the first wiki which comes with SOAP server 
support. But someone should come up with a decent wiki.wdsl to define 
the methods how to control the engine.

Please see http://phpwiki.sourceforge.net/phpwiki/PhpWiki.wdsl

Initial code is checked in but will need some time to progagate through 
sourceforge.
PS: The original wdsl comes from another phpwiki,
   http://www.wlug.org.nz/SOAP
But this has just one method. Get a page content.

BTW: The new Wiki (=tiki) RFC makes progress.
   http://www.ietf.org/mail-archive/ietf/Current/msg24290.html
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: Standard Content Storage API

[Reini U. <ru...@x-...>]

SF Markus Elfring schrieb:
> How do you think about the support for a SOAP interface?
> http://en.wikipedia.org/wiki/Simple_Object_Access_Protocol

PhpWiki has now experimental SOAP support, using the nusoap library.

The first plugin is using the Google API, the Amazon plugin will come soon.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] New feature setAnonEditUnknownLinks

[Reini U. <ru...@x-...>]

New feature in CVS code.
See below:

Reini Urban schrieb:
> Update of /cvsroot/phpwiki/phpwiki/themes/default
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14587/themes/default
> 
> Modified Files:
> 	themeinfo.php 
> Log Message:
> First PagePerm implementation:
> 
> $Theme->setAnonEditUnknownLinks(false);
> 
> Layout improvement with dangling links for mostly closed wiki's:
> If false, only users with edit permissions will be presented the 
> special wikiunknown class with "?" and Tooltip.
> If true (default), any user will see the ?, but will be presented 
> the PrintLoginForm on a click.
> 
> 
> Index: themeinfo.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/themes/default/themeinfo.php,v
> retrieving revision 1.29
> retrieving revision 1.30
> diff -u -2 -b -p -d -r1.29 -r1.30
> --- themeinfo.php	5 Dec 2003 01:31:51 -0000	1.29
> +++ themeinfo.php	28 Feb 2004 22:25:06 -0000	1.30
> @@ -26,5 +26,4 @@ $Theme->addAlternateCSS(_("Top & bottom 
>  $Theme->addAlternateCSS(_("Modern"), 'phpwiki-modern.css');
>  
> -
>  /**
>   * The logo image appears on every page and links to the HomePage.
> @@ -61,4 +60,13 @@ $Theme->setButtonSeparator("\n | ");
>  //$Theme->setAutosplitWikiWords(false);
>  
> +/**
> + * Layout improvement with dangling links for mostly closed wiki's:
> + * If false, only users with edit permissions will be presented the 
> + * special wikiunknown class with "?" and Tooltip.
> + * If true (default), any user will see the ?, but will be presented 
> + * the PrintLoginForm on a click.
> + */
> +//$Theme->setAnonEditUnknownLinks(false);
> +
>  /*
>   * You may adjust the formats used for formatting dates and times
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: Standard Content Storage API

[Reini U. <ru...@x-...>]

SF Markus Elfring schrieb:
>>PhpWiki is usually not that strong in content exchange, but we do have 
>>content syndication of the headlines via RSS 0.9 and 1.0
>>and we do support XML-RPC 1 and 2
>>
>>http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface
>>http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface2
> 
> How do you think about the support for a SOAP interface?
> http://en.wikipedia.org/wiki/Simple_Object_Access_Protocol

Well, good timing.
I'm just thinking of adding the nosoap classes to PhpWiki. This would be 
the required SOAP layer.
   http://dietrich.ganx4.com/nusoap
Users might optionally require CURL for https transactions.

Initially I thought only of Amazon and Google queries, because these 
requires SOAP.
Well, why not?

>>Since the java support will grow and even some of my lisp colleagues do 
>>a lot of java bridging I consider it a good thing.
> 
> I would like to see a PHP class library that can be used like the Java API.

syntax or feature-wise or quality?

>>What kind of sample applications can you imagine?
>>E.g. let a tomcat java app make use of PhpWiki content?
> 
> Yes, of course.
> Data should be reusable between different content management systems.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Table of Content for a Page

[Alessandro V. <av...@sc...>]

Reini Urban wrote:

>> Is there a way to have PhpWiki generate a table of content for some 
>> pages? [...]

> Not yet, but we discussed it lately.
> CreateToc or AutoToc.

Sounds good. I saw that discussion just a few minutes after sending my 
email :).

> Right now we have to bring out 1.3.8 and then
> it's just a matter of 60 minutes work.

I can't wait! And keep up the good work on PhpWiki,

Alex

Re: [Phpwiki-talk] phpxref.sf.net

[Whit B. <wh...@tr...>]

On Sat, Feb 28, 2004 at 01:24:09PM +0100, Reini Urban wrote:

> >>Would this be a useful to understand the source better?
> >>
> >>http://phpxref.sf.net
> 
> we don't have. we have 40MB now, and our quota is 100MB.
> maybe with gzipped html, but then it's on the edge.

Went to set it up on space I have, but the tar they have up is garbaged.
I'll write the site maintainer.

Whit

[Phpwiki-talk] Re: Standard Content Storage API

[SF M. E. <el...@us...>]

> PhpWiki is usually not that strong in content exchange, but we do have 
> content syndication of the headlines via RSS 0.9 and 1.0
> and we do support XML-RPC 1 and 2
> 
> http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface
> http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface2

How do you think about the support for a SOAP interface?
http://en.wikipedia.org/wiki/Simple_Object_Access_Protocol


> Since the java support will grow and even some of my lisp colleagues do 
> a lot of java bridging I consider it a good thing.

I would like to see a PHP class library that can be used like the Java API.


> What kind of sample applications can you imagine?
> E.g. let a tomcat java app make use of PhpWiki content?

Yes, of course.
Data should be reusable between different content management systems.

Re: [Phpwiki-talk] phpxref.sf.net

[Reini U. <ru...@x-...>]

Ok,

For wannabe coders.
The PhpWiki-1.3.4 and PhpWiki-1.3.8 xref trees are now available for 
browsing at:

   http://xarch.tu-graz.ac.at/~rurban/phpwiki-1.3.4/xref/
   http://xarch.tu-graz.ac.at/~rurban/phpwiki-1.3.8/xref/
and the always current version at
    http://xarch.tu-graz.ac.at/~rurban/phpwiki/xref/

The files containing passwords are removed, my phpxref.cfg is there, all 
my extensions and modules I'm currently working at are also there.
(Not so many)

Reini Urban schrieb:
> Would this be a useful to understand the source better?
> http://phpxref.sf.net
> sample: http://de.tikiwiki.org/xref-fix/nav.html?index.html
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] More features (me too)

[Whit B. <wh...@tr...>]

On Sat, Feb 28, 2004 at 05:27:46PM +0100, Reini Urban wrote:

> yes, xaraya. another split in the nuke community...

> code looks fine, just those long function prefixes, and the
> web page looks too professional (closed),

The Xaraya Webpage style is based on the constraints of doing brochures in
2, 3 or 4 color printing - where you put a whole lot in a single shade
because you can't afford a full-color approach. Nothing like immitating a
prior technology while pretending to be on the forefront of the next. Maybe
they'll progress from this to a page entirely in distressed typewriter font.

After looking at many of the wiki implementations out there, part of
PhpWiki's appeal was the clean appearance. I had to consciously discount for
its looking better to focus on appraising the functional features. It's
_hard_ in design to do simple well. Layering on design motifs for no purpose
just clutters the world with noise.

Whit

RE: [Phpwiki-talk] More features (me too)

[Electrawn \(J. Potkanski\) <ele...@ya...>]

I still have much love for postnuke, with all its broken development. Has
something to do with the tons of modules available for it.

Want something pretty? Look at www.xoops.org . That is _pretty_ code.


ph...@de... schrieb:
> On Wed, 25 Feb 2004 00:50:01 +0100, Reini Urban <ru...@x-...> wrote:
> => I seem to like postnuke's features.
> 	<snip>
> => PhpWiki is technically soo much better than postnuke, so it makes 
> => writing new modules here more fun than there. It just looks better 
> => there, admitted.
> 
> 	I haven't posted to the list in a couple years.  My Wikis are very
old
> now but still running fine with happy users.  I'm very much looking
forward to
> the new stable 1.38 (and 1.4.0) - thanks from a non-coding lurker.
> 
> 	Anyway, if you like the xxnuke CMS approach and are interested in
wiki
> implementation related to them, I'd highly recommend looking at the next
leap
> forward from phpnuke and postnuke: www.xaraya.com - its development
community
> was a spin-off from the implosion at postnuke and they've done an
incredbile
> job and are almost at their magical 1.0 release:
> 	http://www.xaraya.com/
> I think you'd like it, especial as a "former lisp programmer".

yes, xaraya. another split in the nuke community...
their code is a bit better than ours. any a bit more lines.

code looks fine, just those long function prefixes, and the
web page looks too professional (closed),
without any user interaction which should drive this. looks like they 
need money but no users.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] More features (me too)

[Reini U. <ru...@x-...>]

ph...@de... schrieb:
> On Wed, 25 Feb 2004 00:50:01 +0100, Reini Urban <ru...@x-...> wrote:
> => I seem to like postnuke's features.
> 	<snip>
> => PhpWiki is technically soo much better than postnuke, so it makes 
> => writing new modules here more fun than there. It just looks better 
> => there, admitted.
> 
> 	I haven't posted to the list in a couple years.  My Wikis are very old
> now but still running fine with happy users.  I'm very much looking forward to
> the new stable 1.38 (and 1.4.0) - thanks from a non-coding lurker.
> 
> 	Anyway, if you like the xxnuke CMS approach and are interested in wiki
> implementation related to them, I'd highly recommend looking at the next leap
> forward from phpnuke and postnuke: www.xaraya.com - its development community
> was a spin-off from the implosion at postnuke and they've done an incredbile
> job and are almost at their magical 1.0 release:
> 	http://www.xaraya.com/
> I think you'd like it, especial as a "former lisp programmer".

yes, xaraya. another split in the nuke community...
their code is a bit better than ours. any a bit more lines.

code looks fine, just those long function prefixes, and the
web page looks too professional (closed),
without any user interaction which should drive this. looks like they 
need money but no users.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] More features (me too)

[<ph...@de...>]

On Wed, 25 Feb 2004 00:50:01 +0100, Reini Urban <ru...@x-...> wrote:
=> I seem to like postnuke's features.
	<snip>
=> PhpWiki is technically soo much better than postnuke, so it makes 
=> writing new modules here more fun than there. It just looks better 
=> there, admitted.

	I haven't posted to the list in a couple years.  My Wikis are very old
now but still running fine with happy users.  I'm very much looking forward to
the new stable 1.38 (and 1.4.0) - thanks from a non-coding lurker.

	Anyway, if you like the xxnuke CMS approach and are interested in wiki
implemmentation related to them, I'd highly recommend looking at the next leap
forward from phpnuke and postnuke: www.xaraya.com - its development community
was a spin-off from the implosion at postnuke and they've done an incredbile
job and are almost at their magical 1.0 release:
	http://www.xaraya.com/
I think you'd like it, especial as a "former lisp programmer".

	Thanks again for all the hard work,

	- Don
(who fooled with lisp in 1969 until it over stretched his mind)

Re: [Phpwiki-talk] phpxref.sf.net

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> Reini Urban schrieb:
>> Would this be a useful to understand the source better?
>>
>> http://phpxref.sf.net
>> sample: http://de.tikiwiki.org/xref-fix/nav.html?index.html
>>
>> should be easy to setup on sf.net, if there's enough space left.
> 
> phpxref for phpwiki 1.3.8 needs 76 MB
> steve, do we have this enough webspace on sf.net?

we don't have. we have 40MB now, and our quota is 100MB.
maybe with gzipped html, but then it's on the edge.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Table of Content for a Page

[Reini U. <ru...@x-...>]

Alessandro Vernet schrieb:
> Is there a way to have PhpWiki generate a table of content for some 
> pages? The table of content would be generated automatically based on 
> the titles in the page (!!!, !!, !). Wikipedia does this, see for 
> instance: http://en.wikipedia.org/wiki/Psychosis

Not yet, but we discussed it lately.
CreateToc or AutoToc.

Right now we have to bring out 1.3.8 and then
it's just a matter of 60 minutes work.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Standard Content Storage API

[Reini U. <ru...@x-...>]

SF Markus Elfring schrieb:
>>Hi, could you please describe shortly what that is, what it means,
>>and why we should support that?
> 
> Java Specification Request 170 is the development of a single API to get access to the 
 > following interfaces and more.
> - http://en.wikipedia.org/wiki/WebDAV
> - http://en.wikipedia.org/wiki/Information_Content_Exchange
> 
> Can you image to use that?
> Please consider the specification "Scripting Pages in JavaTM Web 
 > Applications" (http://jcp.org/en/jsr/detail?id=223), too.

Sounds sound, but not me.
Maybe some of the PhpWiki developers team will do it.
New and useful technologies usually excite them, if I remember
correctly :)

PhpWiki is usually not that strong in content exchange, but we do have 
content syndication of the headlines via RSS 0.9 and 1.0
and we do support XML-RPC 1 and 2

http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface
http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface2

And there are some other plugins which do exchange whole content also, 
e.g. irc channel content => phpwiki.

Since the java support will grow and even some of my lisp colleagues do 
a lot of java bridging I consider it a good thing.
What kind of sample applications can you imagine?
E.g. let a tomcat java app make use of PhpWiki content?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Table of Content for a Page

[Alessandro V. <av...@sc...>]

Is there a way to have PhpWiki generate a table of content for some 
pages? The table of content would be generated automatically based on 
the titles in the page (!!!, !!, !). Wikipedia does this, see for 
instance: http://en.wikipedia.org/wiki/Psychosis

Alex

Re: [Phpwiki-talk] Re: Wiki RFC Discussion

[Whit B. <wh...@tr...>]

On Sat, Feb 28, 2004 at 08:54:50AM +1200, Franck Martin wrote:
> 
> I suggest
> 
> **bold** This is used in e-mails a lot...
> 
> __underlining__  This one does not provide backward compatibility but 
> seems more logical

What seems logical will depend on where the user is coming from. Back when
manuscripts were prepared by typewriters, which didn't have italics of
course, the _ character when used to underline meant 'italics'. In normal
printed English there is no use of underlining; italics and bold are pretty
much it, aside from type size. 

And nobody wants to type more complexly in a wiki than they have to. So
what's the logic of not doing *bold*, _italics_, _*bold italics*_ and
perhaps __underlining__, ___underlined italics___, __*underlined bold*__,
___*underlined bold italics*___ - since that means the most typing for the
least-used effects.

Just my two cents. Hopefully many of the implementations will allow these to
be configured locally (with export options of course)....

Whit

[Phpwiki-talk] Re: Wiki RFC Discussion

[Franck M. <fr...@so...>]

All these changes seem fine by me...

Please use the comments area on the page, to record your comments 
regarding the syntax.
http://tikiwiki.org/tiki-index.php?page=RFCWiki

I think we are not worried if the syntax breaks the current tiki, as the 
tiki group is looking for establishing a Wiki API.

We will try to ensure we can implement the new syntax while providing 
backward compatibility.

I suggest

Philippe Cloutier wrote:

> electron wrote:
>
>
>>
>>
>> 2.22. Adding Hidden Details in Lists An expandable area allows you to 
>> display the major items in your list by
>> default. Every item is still there, but it needs to be expanded to 
>> become
>> visible. An expandable area is created by adding a minus (-) 
>> character after
>> the star (*) characters.
>> Example: *This is a Level 1 item. *This Level 1 item has Hidden 
>> Details. Click the Plus [+] to open it. **-This is a Level 2 item. 
>> Clicking the Minus [-] will close it. **This Level 2 item did not 
>> need the minus character. *Back to Level 1.
>> Expandable areas work with Bulleted and Numbered lists.
>> ---
>>
>> This can cause some really strange behaviors and puzzled users. 
>> ("Where did
>> my text go?!!") Possibly require the previous line has a +, such as:
>>
>> Example: *This is a Level 1 item. *+This Level 1 item has Hidden 
>> Details. Click the Plus [+] to open it. **-This is a Level 2 item. 
>> Clicking the Minus [-] will close it. **This Level 2 item did not 
>> need the minus character. *Back to Level 1.
>> Maybe that was an omission?
>>
>>  
>>
> I don't really understand the objection, as why is *+ on second line? 
> Obviously users can be puzzled a bit at first time. We use it (and 
> also for titles) in TikiWiki documentation though, and it's pretty 
> useful.
>
I think it is an omission....

>>
> I'm posting this to Tiki devel-list.
> A comment on syntax I already received from a Tiki admin was that 
> using __ for bold instead of underlining (currently ===) was strange. 
> This makes sense to me at first glance. Luis Argerich first 
> implemented that syntax, I think it would be interesting to get his 
> comments on those changes.
>
> Philippe Cloutier


I suggest

**bold** This is used in e-mails a lot...

__underlining__  This one does not provide backward compaqtibility but 
seems more logical

About XML, my idea is that if an application needs to differentiate from 
a plain text document to a wiki document, then the word wiki must be 
start on the first character of the first line. No others words are 
permitted on the line...
In a wiki application this feature is unlikely to be used, but in an 
e-mail document it could be useful...

I don't think wiki documents should have a version number.

Cheers

-- 
Franck Martin
ICT Specialist
fr...@so...
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

[Phpwiki-talk] Re: Standard Content Storage API

[SF M. E. <el...@us...>]

> Hi, could you please describe shortly what that is, what it means,
> and why we should support that?

Java Specification Request 170 is the development of a single API to get access to the following interfaces and more.
- http://en.wikipedia.org/wiki/WebDAV
- http://en.wikipedia.org/wiki/Information_Content_Exchange

Can you image to use that?
Please consider the specification "Scripting Pages in JavaTM Web Applications" (http://jcp.org/en/jsr/detail?id=223), too.