TiddlySnip and ccTiddly, ZiddlyWiki

[Saq Imtiaz]

Hey guys,

I'm ready to start work on getting TiddlySnip compatible with these two serversides. However, there are few things I need to discuss with CoolCold and Bob first... Please verify the information provided below and try to fill in the blanks.

Regarding ZW:
Here is the information I currently have:
Post requests:

• URL : http://your.site/etc/?action=save
• title: tiddler title
• body: tiddler body
• tags: tiddler tags
• modified: TW modification
• created: TW
• id: zope-specific id

Get:

• http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc

Information needed:

1. what kind of feedback does ZW provide in response to the Post requests? Some kind of error/status codes are needed to indicate whether the tiddler was saved or not.
2. what happens if I Post a tiddler that already exists, will it be overwritten?
3. Is there any possibility someone could provide a test ZW for me to use to help get this working? I dont have access to a server to set one up. (Preferrably a version that doesnt ahve the zope-specific-id requirement.
   
4. Anyone willing and able to get me started on the right direction regarding Http basis authentication when doing POSTS ?

ccTiddly
first off, thanks for the test site CoolCold!
Post requests:

• url: http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php
  
• action: TiddlySnip
• title: tiddler title
• body: tiddler body
• tags: tiddler tags
• user: username
• password: password in plain text
• overwrite: required to specify overwrite

Error/Status codes:

• 001: tiddler added to store (success)
• 002: tiddler already exists
• 003: invalid username and password (not used)
• 004: no privilege
• 005: unknown error

Information needed:

1. Does ccT need arguments for tiddler created and tiddler modified?
2. can ccT provide the ability to get single tiddlers like ZW does? ( http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc)

And for both ZW and ccT, will the serversides support the upcoming extended fields feature being introduced in TW 2.1? I am asking because some future features that we have planned for TiddlySnip will be based on this.

Cheers,
Saq

[Bob McElrath]

Saq Imtiaz [lew...@gmail.com] wrote:
> Hey guys,
>
> I'm ready to start work on getting TiddlySnip compatible with these two
> serversides. However, there are few things I need to discuss with CoolCold
> and Bob first... Please verify the information provided below and try to
> fill in the blanks.
>
> Regarding ZW:
> Here is the information I currently have:
> Post requests:
>

> - URL : http://your.site/etc/?action=save
> - title: tiddler title
> - body: tiddler body
> - tags: tiddler tags
> - modified: TW modification
> - created: TW
> - id: zope-specific id

The parameter 'id' can (and should be) be omitted. Only use it if
you're trying to modify a tiddler that you obtained from this ZW
instance and already have its id.

> Get:
>
> - http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc
>
> Information needed:
>
> 1. what kind of feedback does ZW provide in response to the Post

> requests? Some kind of error/status codes are needed to indicate whether the
> tiddler was saved or not.

It returns a redirect to a 'get' request. (which will be followed by
the browser) So the response you will see is the same as a regular
'get' request.

> 2. what happens if I Post a tiddler that already exists, will it be
> overwritten?

Yes. There is a history mechanism however, so this can in principle be
undone. (Can't be undone through TW right now -- but I plan to add
that)

> 3. Is there any possibility someone could provide a test ZW for me to

> use to help get this working? I dont have access to a server to set one up.
> (Preferrably a version that doesnt ahve the zope-specific-id requirement.

I have created one for you here:
http://ziddlywiki.com/TiddlySnip
this is based on the new unreleased 2.1 branch of ZiddlyWiki, and may be
unstable. Please report any bugs you find... If you don't have a login
you can create one here:
http://ziddlywiki.com/cookie_auth/signup

> 4. Anyone willing and able to get me started on the right direction

> regarding Http basis authentication when doing POSTS ?

I don't know about this...it may work "automatically" -- just try the
POST and the user should be presented with the auth dialog. Note that
the above site uses cookie-based auth rather than HTTP Basic.

> ccTiddly
> first off, thanks for the test site CoolCold!
> Post requests:
>

> - url: http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php
> - action: TiddlySnip
> - title: tiddler title
> - body: tiddler body
> - tags: tiddler tags
> - user: username
> - password: password in plain text
> - overwrite: required to specify overwrite

I would really like to unify this, so TiddlySnip doesn't have to care
about which kind of server it's talking to. Can ccTiddly use HTTP or
cookie auth (which would remove user/password)? 'action' seems
superfluous, as this action should be identical to a save, no? And
lastly, do we really need 'overwrite'? I'm willing to consider
it...convince me.

> Error/Status codes:
>
> - 001: tiddler added to store (success)
> - 002: tiddler already exists
> - 003: invalid username and password (not used)
> - 004: no privilege
> - 005: unknown error

I do not understand the need for these error messages. 001 and 002
should be the same, if 002 overwrites the tiddler, which (at least for
ZW) isn't an irreversible error. Note the 200 (OK) and 201 (Created)
HTTP response codes.

003 and 004 should return a HTTP 401 or 403 (unauthorized) error.

And I don't know why 005 should exist. ;) But I suspect returning an
HTTP 550 Internal Server Error is a better idea.

> Information needed:
>
> 1. Does ccT need arguments for tiddler created and tiddler modified?
> 2. can ccT provide the ability to get single tiddlers like ZW does?

> (http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc
> )
>
> And for both ZW and ccT, will the serversides support the upcoming extended
> fields feature being introduced in TW 2.1? I am asking because some future
> features that we have planned for TiddlySnip will be based on this.

Ummm...maybe. How exactly are fields stored? How do you expect server
sides to deal with them? I thought this was to do with tiddler slicing,
in which case the content is part of the tiddler text itself, and
doesn't need to be replicated again.

I have actually used a field for the "revisionKey" which tracks
revision/undo. But the use of fields is not general. (yet)

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

Somewhere, something incredible is waiting to be known. - Carl Sagan

[Saq Imtiaz]

On 9/15/06, Bob McElrath <bob.mc...@gmail.com> wrote:

>    3. Is there any possibility someone could provide a test ZW for me to
>    use to help get this working? I dont have access to a server to set one up.
>    (Preferrably a version that doesnt ahve the zope-specific-id requirement.

I have created one for you here:
    http://ziddlywiki.com/TiddlySnip
this is based on the new unreleased 2.1 branch of ZiddlyWiki, and may be
unstable.  Please report any bugs you find...  If you don't have a login
you can create one here:
    http://ziddlywiki.com/cookie_auth/signup

Thanks Bob, that will be very helpful indeed.

>    4. Anyone willing and able to get me started on the right direction
>    regarding Http basis authentication when doing POSTS ?

I don't know about this...it may work "automatically" -- just try the
POST and the user should be presented with the auth dialog.  Note that
the above site uses cookie-based auth rather than HTTP Basic.

Ok, I'll experiment and see what we can come up with.

> ccTiddly
> first off, thanks for the test site CoolCold!
> Post requests:
>
>    - url: http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php
>    - action: TiddlySnip
>    - title: tiddler title
>    - body: tiddler body
>    - tags: tiddler tags
>    - user: username
>    - password: password in plain text
>    - overwrite: required to specify overwrite

I would really like to unify this, so TiddlySnip doesn't have to care
about which kind of server it's talking to. 

:) That would make my day!

 Can ccTiddly use HTTP or
cookie auth (which would remove user/password)?  'action' seems
superfluous, as this action should be identical to a save, no?  And
lastly, do we really need 'overwrite'?  I'm willing to consider
it...convince me.

Cant comment on the rest, but regarding the overwrite and the "002: tiddler already exists" code mentioned below.... from what I now, ccT does not offer a way of fetching a single tiddler via  a GET request. So, I have no way of checking  if a user is about to overwrite a tiddler or not. Therefore I asked for a "tiddler already exists" error code to be returned, so I can them prompt the user to rename or overwrite.

With ZW what I am planning is to do a get request to check if the tiddler exists, and then proceed accordingly. If ccTiddly could offer the possibility of either fetching or checking for the existence of a single tiddler via a GET request, then we wouldnt need the 002 error code. And ccT could then automatically overwrite existing tiddlers when receiving the Post.

> Error/Status codes:
>
>    - 001: tiddler added to store (success)
>    - 002: tiddler already exists
>    - 003: invalid username and password (not used)
>    - 004: no privilege
>    - 005: unknown error

I do not understand the need for these error messages.  001 and 002
should be the same, if 002 overwrites the tiddler, which (at least for
ZW) isn't an irreversible error.  Note the 200 (OK) and 201 (Created)
HTTP response codes.

003 and 004 should return a HTTP 401 or 403 (unauthorized) error.

And I don't know why 005 should exist.  ;)  But I suspect returning an
HTTP 550 Internal Server Error is a better idea.

The exact nature of the  error/status messages dont matter to me personally, as long as I know what they will be.  I've explained about 002 above. As for 003/004,  its needed because of the way ccT handles logins (username and password in the POST). 005, I'm not sure about either, I think CoolCold added that as a second thought.

> And for both ZW and ccT, will the serversides support the upcoming extended
> fields feature being introduced in TW 2.1? I am asking because some future
> features that we have planned for TiddlySnip will be based on this.

Ummm...maybe.  How exactly are fields stored?  How do you expect server
sides to deal with them?  I thought this was to do with tiddler slicing,
in which case the content is part of the tiddler text itself, and
doesn't need to be replicated again.

Tiddler slices are as you mentioned, part of the tiddler text. Tiddler fields are extended data fields similar to the tiddler.tags and tiddler.title. They are saved as attributes of the tiddler div in a regular TW.
Eg:

<div tiddler=
"Force refresh when loading new url?" modifier="Saq" modified=
"200609032033" created="200609032033" tags="TiddlySnip " 
tsnip.url="http://forums.mozillazine.org/" tsnip.title
="Force" tsnip.category="default">var newTab </div>

Note the tsnip attributes, these are extended fields.
With TiddlySnip we plan to use these to track where 'snippet's were saved from, as there is a tentative idea to pull data in the other direction in a future version. That is, when you view a webpage that you saved a snippet from, the snippet will be shown overlayed over the page in a resizable, moveable and editable div. Very tentative idea though.

But regarding extended fields in general, I have a strong feeling a LOT of future plugins will be using them, so thats a pretty good reason to try and support them.

Cheers,
Saq

[Bob McElrath]

Forgive me for coming late to the 'tiddler fields' discussion...

Tiddler fields are not valid XML. Isn't that a problem? I thought we
were heading toward XML not away from it.

In my mind to store data this way is really abusing an unexpected
behavior of browsers, and that behavior might go away...

What ever happened with the XHTML compliant store? How will it store
tiddler fields, and are we going to transition to an XHTML compliant
store?

Saq Imtiaz [lew...@gmail.com] wrote:
> Tiddler slices are as you mentioned, part of the tiddler text. Tiddler
> fields are extended data fields similar to the tiddler.tags and
> tiddler.title. They are saved as attributes of the tiddler div in a regular
> TW.
> Eg:
>
> <div tiddler="Force refresh when loading new url?" modifier="Saq"
> modified="200609032033" created="200609032033" tags="TiddlySnip "

> tsnip.url="http://forums.mozillazine.org/" tsnip.title="Force"

> tsnip.category="default">var newTab </div>
>
> Note the tsnip attributes, these are extended fields.
> With TiddlySnip we plan to use these to track where 'snippet's were saved
> from, as there is a tentative idea to pull data in the other direction in a
> future version. That is, when you view a webpage that you saved a snippet
> from, the snippet will be shown overlayed over the page in a resizable,
> moveable and editable div. Very tentative idea though.
>
> But regarding extended fields in general, I have a strong feeling a LOT of
> future plugins will be using them, so thats a pretty good reason to try and
> support them.

Ok I'll keep this in mind.

[Saq Imtiaz]

On 9/15/06, Bob McElrath <bob.mc...@gmail.com> wrote:

Forgive me for coming late to the 'tiddler fields' discussion...

Tiddler fields are not valid XML.  Isn't that a problem?  I thought we
were heading toward XML not away from it.

In my mind to store data this way is really abusing an unexpected
behavior of browsers, and that behavior might go away...

What ever happened with the XHTML compliant store?  How will it store
tiddler fields, and are we going to transition to an XHTML compliant
store?

I'm no authority on this, but I suspect the plan may be to offer XHTML compliance via a plugin:
http://tiddlywiki.abego-software.de/#XHTML10Plugin

As someone not so technically knowledgeable about these things, I am curious, why would you want XHTML comliance? what benefits would it offer?

Cheers,
Saq

Saq Imtiaz [lew...@gmail.com] wrote:
> Tiddler slices are as you mentioned, part of the tiddler text. Tiddler
> fields are extended data fields similar to the tiddler.tags and
> tiddler.title. They are saved as attributes of the tiddler div in a regular
> TW.
> Eg:
>
> <div tiddler="Force refresh when loading new url?" modifier="Saq"
> modified="200609032033" created="200609032033" tags="TiddlySnip "
> tsnip.url="http://forums.mozillazine.org/" tsnip.title="Force"
> tsnip.category="default">var newTab </div>
>
> Note the tsnip attributes, these are extended fields.
> With TiddlySnip we plan to use these to track where 'snippet's were saved
> from, as there is a tentative idea to pull data in the other direction in a
> future version. That is, when you view a webpage that you saved a snippet
> from, the snippet will be shown overlayed over the page in a resizable,
> moveable and editable div. Very tentative idea though.
>
> But regarding extended fields in general, I have a strong feeling a LOT of
> future plugins will be using them, so thats a pretty good reason to try and
> support them.

Ok I'll keep this in mind.

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    Somewhere, something incredible is waiting to be known. - Carl Sagan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFCkWCjwioWRGe9K0RAjsTAKDZvjQHaF7HyJ1ma3cxfXqJ/Le0HACg52Pj
o0sjOvVPUtQOWNVO0j+V95k=
=SC0g
-----END PGP SIGNATURE-----

[Udo Borkowski]

Tiddler fields are not valid XML.  Isn't that a problem?  I thought we
were heading toward XML not away from it.

If desired an XHTML compliant store format can be used, by installing the XHTML10Plugin
(http://tiddlywiki.abego-software.de/#XHTML10Plugin). (Announced in http://groups.google.com/group/TiddlyWikiDev/browse_frm/thread/fe8cc2364d7df0e6/ce47530bf7c6cd38)

What ever happened with the XHTML compliant store?  How will it store
tiddler fields, and are we going to transition to an XHTML compliant
store?

Currently this plugin is located at my site but I will move it to the tiddlywiki.org site as soon as 2.1 is released.

Here an example tiddler in XHTML format, as stored by that plugin (with extra whitespace for nicer reading)

<div title="SampleTitle">
	<pre title="title">SampleTitle</pre>
	<pre title="text">SampleText</pre>
	<pre title="modifier">UdoBorkowski</pre>
	<pre title="modified">200609150639</pre>
	<pre title="created">200609011146</pre>
	<pre title="tags">SampleTag1 SampleTag2</pre>
</div>

Udo

----------
Udo Borkowski
http://www.abego-software.de

[Bob McElrath]

Saq Imtiaz [lew...@gmail.com] wrote:
> On 9/15/06, Bob McElrath <bob.mc...@gmail.com> wrote:
> >
> > Forgive me for coming late to the 'tiddler fields' discussion...
> >
> > Tiddler fields are not valid XML. Isn't that a problem? I thought we
> > were heading toward XML not away from it.
> >
> > In my mind to store data this way is really abusing an unexpected
> > behavior of browsers, and that behavior might go away...
> >
> > What ever happened with the XHTML compliant store? How will it store
> > tiddler fields, and are we going to transition to an XHTML compliant
> > store?
>
>
> I'm no authority on this, but I suspect the plan may be to offer XHTML
> compliance via a plugin:
> http://tiddlywiki.abego-software.de/#XHTML10Plugin
>
> As someone not so technically knowledgeable about these things, I am
> curious, why would you want XHTML comliance? what benefits would it offer?

For one, the store could be processed with standard XML tools.

For two, I can put MathML and SVG in my tiddlywiki.

And for three, abusing browser bugs to create features is a recipe for
future disasters, when one browser decides to suddenly stop honoring
random attributes. (But, if some spec says these attributes are
required to be made available in the DOM, I'd be interested...)

[Udo Borkowski]

I forgot to mention that the "extended fields" are stored in the same way as standard fields. E.g.

	<pre title="priority">3</pre>

Udo

----------
Udo Borkowski
http://www.abego-software.de

[Bob McElrath]

I like that. Oh and doing fields this way lets one name their tiddler
fields in Korean. (or any other character set that is not allowed in
the name of an attribute)

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
> To post to this group, send email to Tiddly...@googlegroups.com
> To unsubscribe from this group, send email to TiddlyWikiDe...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev
> -~----------~----~----~----~------~----~------~--~---

[Saq Imtiaz]

I had actually started on writing separate code for saving to ccT and ZW, but I'm very keen for a unified implementation... so I'm going to wait for CoolCold to reply and see if we can work something out. A unified implementation might prove useful in the future for purposes other than TiddlySnip interaction as well.

The key differences seems to be:
1) the login procedure
2) ccT needs to provide the possibility to fetch single tiddlers via Get requests.

Cheers,
Saq

[Saq Imtiaz]

So, *if* XHTML compliance is beneficial, why aren't we adopting that as the norm? The extra  (file-size) overhead perhaps?

Saq

[Udo Borkowski]

And for three, abusing browser bugs to create features is a recipe for
future disasters, when one browser decides to suddenly stop honoring
random attributes.  

A browser that "decides to suddenly stop honoring random attributes" would not be compliant with the HTML 4.01 Spec since it states in "B.1":

• If a user agent encounters an attribute it does not recognize, it should ignore the entire attribute specification (i.e., the attribute and its value).

("user agent" here means "browser").

So I would not call our usage of attributes in the standard storage format "abusing browser bugs". It's HTML.

Udo

----------
Udo Borkowski
http://www.abego-software.de



Bob McElrath wrote:

[Udo Borkowski]

As I see it the average "John Doe" user will not really have benefits
from XHTML compliance, so there is no need to put the extra burden (like
filesize) into the standard installation. If XHTML compliance is really
required/beneficial, this can easily be done by just adding the XHTML
plugin. Existing tiddlers in the store are converted to XHTML
automatically.

Udo

----------
Udo Borkowski
http://www.abego-software.de

[Udo Borkowski]

Oh and doing fields this way lets one name their tiddler
fields in Korean. 

I am sorry to disappoint you, Bob, but koreans have to stick to "a-z0-9_." characters, and also I cannot use "Umlauts" etc..

A field name must match this regular expression:
        [a-zA-Z_]\w*(\.[a-zA-Z_]\w*)*

[coolcold]

Hi guys,

Sorry for late reply. Answers below

> Information needed:
>
> 1. Does ccT need arguments for tiddler created and tiddler modified?
ccT don't need these two arguement. I can take both though, just a line
of code change really.

> 2. can ccT provide the ability to get single tiddlers like ZW does?
> (http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc
> )
Not implemented yet. Would you like it in regular TW form with a single
div in the storeArea? Or just the requested tiddler in div form?

>
> And for both ZW and ccT, will the serversides support the upcoming extended
> fields feature being introduced in TW 2.1? I am asking because some future
> features that we have planned for TiddlySnip will be based on this.

I actually have not played with TW 2.1 yet so there won't be support
for those at the moment.

[coolcold]

>I would really like to unify this, so TiddlySnip doesn't have to care

>about which kind of server it's talking to. Can ccTiddly use HTTP or

>cookie auth (which would remove user/password)?

I believe I can use cookie auth. Not sure what the path would be like
so I need to test it first.

> 'action' seems
>superfluous, as this action should be identical to a save, no?

Well, yes and no. They are mostly identical except overwrite and user
validation part

>And
>lastly, do we really need 'overwrite'? I'm willing to consider
>it...convince me.

I can default the action to append if you want to strip it. I used that
because there is a scenerio where the user can't read the tiddler but
are allow to insert/edit it. So there could be problem in that case.
Not that it would definitely happen (given this is a pretty weird
scenerio) but the system currently allows this kind of flexibility.

>005, I'm not sure about either, I think CoolCold added that as a second thought.

This is added as a kind of reserve. I have only use this as an error
catch and I also don't know about ZW's error code.

>> 2. what happens if I Post a tiddler that already exists, will it be
>> overwritten?

>Yes. There is a history mechanism however, so this can in principle be
>undone. (Can't be undone through TW right now -- but I plan to add
>that)

It may not be so bad for ZW since the history is show right on top of
the tiddler and the user can check quite quickly. Unfortunately, ccT is
not that advance yet and have to visit a different url for previous
history. The user might not know that a tiddler have been overwritten
and data is lost unnoticed.

So I don't mind dropping error code and use header instead. I do prefer
to have the overwrite variable though so the user is notified when a
tiddler can't be overwritten.

[Saq Imtiaz]

On 9/15/06, coolcold <google....@dfgh.net> wrote:

Hi guys,

Sorry for late reply. Answers below

> Information needed:
>
>    1. Does ccT need arguments for tiddler created and tiddler modified?
ccT don't need these two arguement. I can take both though, just a line
of code change really.

Ideally I feel this should be handled on the server-side.
Currently ZW requires these arguments, but ccT does not. I don't have a problem either way. TiddlySnip can provide these, but you guys needs to decide which one of you has to change. ;)

>    2. can ccT provide the ability to get single tiddlers like ZW does?
> (http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc
>    )
Not implemented yet. Would you like it in regular TW form with a single
div in the storeArea? Or just the requested tiddler in div form?

This is probably the most important part. If we can get this working, it will help with the error codes and the overwrite too.
At this time, I dont have a personal preference for the format of the tiddler, but it makes sense to use the same as ZW.

Have a look at:
http://www.ziddlywiki.com/doc?action=get&id=TiddlyDoc
and compare with: http://www.ziddlywiki.com/doc
 

Cheers,
Saq

[Saq Imtiaz]

On 9/15/06, coolcold <google....@dfgh.net> wrote:

>>    2. what happens if I Post a tiddler that already exists, will it be
>>    overwritten?
>Yes.  There is a history mechanism however, so this can in principle be
>undone.  (Can't be undone through TW right now -- but I plan to add
>that)
It may not be so bad for ZW since the history is show right on top of
the tiddler and the user can check quite quickly. Unfortunately, ccT is
not that advance yet and have to visit a different url for previous
history. The user might not know that a tiddler have been overwritten
and data is lost unnoticed.

So I don't mind dropping error code and use header instead. I do prefer
to have the overwrite variable though so the user is notified when a
tiddler can't be overwritten.

CoolCold, if ccT can supply single tiddlers in response to Get requests, as mentioned earlier in this thread, we wont need overwrite. You can default to always overwrite.

TiddlySnip, will check first if the tiddler exists and if it does, will warn the user and ask if it should be overwritten, or appended, or if the new tiddler should be renamed. We are already doing this for local files and for UploadPlugin.

This way the user will not be able to accidentally overwrite a tiddler.

If you guys want to handle this stuff on the server-side, thats fine, but then both ccT and ZW would have to support an overwrite and an append argument.

I think letting TiddlySnip take care of this might be easier.
Cheers,
Saq

PS: CoolCold, whenever you get the time to try it out, do let us know how it went with getting cookie authorization working with ccT.

[Jeremy Ruston]

> So, *if* XHTML compliance is beneficial, why aren't we adopting that as the
> norm? The extra (file-size) overhead perhaps?

File-size was part of the reason, but the main one was backwards
compatibility. The community of tools and plugins around TW is
important, and I'm always trying to minimise the impact on existing
work.

In this case, 2.1 covers the majority of the outstanding XHTML issues,
and allows people who really need XHTML compliance to get it via Udo's
plugin. In the future we may well change the default store format to
XHTML, but that will be a community-driven decision.

Cheers

Jeremy

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[coolcold]

>Currently ZW requires these arguments, but ccT does not. I don't have a
>problem either way. TiddlySnip can provide these, but you guys needs to
>decide which one of you has to change. ;)

Or you can still pass it through and we can decide how to treat it ;)
Since the difference won't be huge (in a matter of seconds?), it
shouldn't be a huge issue

>can ccT provide the ability to get single tiddlers like ZW does?

Sound like its in the form
title
body
modifier
modified
created
tag
If you want, I can put something together similar to this.

>CoolCold, if ccT can supply single tiddlers in response to Get requests, as
mentioned earlier in this thread, we wont need overwrite. You can
default to
always overwrite.

I prefer to have the overwrite variable because of
1/ user may have funny privilege system
2/ history function is not mature in ccT

I would say having a single overwrite function would do. Say
0 = not overwrite/ask for further instruction
1 = overwrite
2 = append

>PS: CoolCold, whenever you get the time to try it out, do let us know how it
went with getting cookie authorization working with ccT.

I need to have a version of TS to test this. I am using cookie to store
the login info at the moment too so the changeover should be stright
forward.

[google....@dfgh.net]

Hi,

Why is this necessary?

CC

[Saq Imtiaz]

On 9/15/06, coolcold <google....@dfgh.net> wrote:

>Currently ZW requires these arguments, but ccT does not. I don't have a
>problem either way. TiddlySnip can provide these, but you guys needs to
>decide which one of you has to change. ;)
Or you can still pass it through and we can decide how to treat it ;)
Since the difference won't be huge (in a matter of seconds?), it
shouldn't be a huge issue

Sure thing, that will be fine.

>can ccT provide the ability to get single tiddlers like ZW does?
Sound like its in the form
title
body
modifier
modified
created
tag
If you want, I can put something together similar to this.

That would be excellent! Use the same format for now, and if the needs arises later we can finetune it.

>CoolCold, if ccT can supply single tiddlers in response to Get requests, as
mentioned earlier in this thread, we wont need overwrite. You can
default to
always overwrite.

I prefer to have the overwrite variable because of
1/ user may have funny privilege system
2/ history function is not mature in ccT

I would say having a single overwrite function would do. Say
0 = not overwrite/ask for further instruction
1 = overwrite
2 = append

Ok, im sure we can work with that. ZW will simply ignore the overwrite variable. I will however be handling the append  on the  clientside, as I believe ZW doesnt have this option.

TIddlySnip will then interact with ccT in this manner:
1/ do a GET to see if tiddler exists
2/ if it exists prompt user to append,rename or overwrite
3/ if user chooses to rename, POST with write=1

if the tiddler does not exist, the POST will have write=0

>PS: CoolCold, whenever you get the time to try it out, do let us know how it
went with getting cookie authorization working with ccT.

I need to have a version of TS to test this. I am using cookie to store
the login info at the moment too so the changeover should be stright
forward.

You are going to need a version of TS that actually supports serversides, which doesnt exist yet. I'll start work on it once you are done with the GET for individual tiddlers. And then we can figure out the cookie authentication together.

So the POST will look like this now:

http_request.send(title=tiddlerTitle&body=bodyOfTiddler&tags=tiddlerTags&modifed=modifed&created=created&overwrite=1);

for a url like: http://your.site/etc/?action=save

Similarly, the url for a GET should be http://your.site/etc/?action=get&id=tiddlerTitle

Does that sound good?
Cheers,
Saq

[google....@dfgh.net]

Ok, im sure we can work with that. ZW will simply ignore the overwrite variable. I will however be handling the append  on the  clientside, as I believe ZW doesnt have this option.

TIddlySnip will then interact with ccT in this manner:
1/ do a GET to see if tiddler exists
2/ if it exists prompt user to append,rename or overwrite
3/ if user chooses to rename, POST with write=1

if the tiddler does not exist, the POST will have write=0

Is the 'write' the same as 'overwrite'? What would happen if I throw back an error saying tiddler existed? Would you give an error message of some kind?

CC

[Saq Imtiaz]

On 9/15/06, google....@dfgh.net <google....@dfgh.net > wrote:

Ok, im sure we can work with that. ZW will simply ignore the overwrite variable. I will however be handling the append  on the  clientside, as I believe ZW doesnt have this option.

TIddlySnip will then interact with ccT in this manner:
1/ do a GET to see if tiddler exists
2/ if it exists prompt user to append,rename or overwrite
3/ if user chooses to rename, POST with write=1

if the tiddler does not exist, the POST will have write=0

Is the 'write' the same as 'overwrite'? What would happen if I throw back an error saying tiddler existed? Would you give an error message of some kind?

Yup, it was actually meant to be overwrite,  a typo on my part. So yeah, overwrite and not write. 

It will just alert something like "Snippet save failed: tiddler already exists"
It will not, at least for now, let the user choose to overwrite.... I dont think this scenario will happen very often so it shouldnt be a problem for now.  Most of the time if the tiddler exists, we will now BEFORE the Post and the user can decide to overwrite or not.

In the future, perhaps I will refactor and allow the user to choose overwrite after the error as well. It's hard to say until I actually start coding. The workflow for local files and UploadPlugin is very similar, but rather different for serversides. And I would like very much to keep the user experience identical, so I'll have to do some thinking and monkey around with the code to get it right.
Cheers,
Saq

Cheers,
Saq

[Udo Borkowski]

Why is this necessary?

Mainly to avoid problems when converting between various storage formats. E.g. as Bob pointed out "theoretically" it would be possible to use non-ASCII fieldnames when using the XHTML plugin. But for the standard store format the fieldname must be a valid (XML) attribute name that does not allow all UNICODE chars. If we would not restrict the possible fieldnames to a "least common denominator" it would not be possible (or at least quite hard) to convert a store from one to another format.

Notice that restricting the fieldname to a certain syntax is not really a big limitiation since fieldnames are used "technically", by "programmers". Normal users rarely notice them. E.g. you may name a field "priority" and present the value of this field near a label "Priorität". This "human readable label" is what interests most users, not the technical field name. BTW: most programming languages use a similar syntax for their "identifiers" as we do for our fieldnames.

Udo

----------
Udo Borkowski
http://www.abego-software.de

[Udo Borkowski]

I haven't followed this discussion in detail, but just a little note:

Sound like its in the form
title
body
modifier
modified
created
tag
If you want, I can put something together similar to this.

You may consider already planning to support extended fields (metadata). Therefore it would probably be a good idea to use the same names as the fieldnames in 2.1. Esp. "body" is called "text" and "tag" is called "tags".

If I misunderstood something, just ignore this mail ;-)

Udo

[coolcold]

ah, gotcha. Somehow I was thinking about the tiddler title instead of
the field name. My bad....

[Saq Imtiaz]

On 9/16/06, Udo Borkowski <Udo.Bo...@gmx.de> wrote:

I haven't followed this discussion in detail, but just a little note:

Sound like its in the form
title
body
modifier
modified
created
tag
If you want, I can put something together similar to this.

You may consider already planning to support extended fields (metadata). Therefore it would probably be a good idea to use the same names as the fieldnames in 2.1. Esp. "body" is called "text" and "tag" is called "tags".

Hey Udo,
the above is just a description of the response text for the following: http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc
They arent field names, so we should be fine.

And TiddlySnip is already using extended fields to keep track of where snippets originated from. :)
Cheers,
Saq

[Saq Imtiaz]

On 9/15/06, Bob McElrath <bob.mc...@gmail.com> wrote:

> Regarding ZW:
> Here is the information I currently have:
> Post requests:
>
>    - URL : http://your.site/etc/?action=save
>    - title: tiddler title
>    - body: tiddler body
>    - tags: tiddler tags
>    - modified: TW modification
>    - created: TW
>    - id: zope-specific id

Bob,  I've run into a problem getting this working. I'm doing a POST to http://ziddlywiki.com/TiddlySnip/?action=save
with the proper arguments.
I get request.status == 200 and request.statusText == OK, and then a redirect to a GET that returns the whole file. However, the tiddler is NOT saved. Furthermore, the behaviour is exactly the same whether I am at that time logged into ZW or not. This leads me to believe its an authorization problem.

Is there any way to verify this? or to see whats going on, on the serverside? and if its a authorization problem, shouldnt ZW return some kind of error?

Cheers,
Saq
PS: I've been reading about how its possible to pass a username and password as arguments in the request.open method. (See table 1 here: http://developer.apple.com/internet/webcontent/xmlhttpreq.html)
Any chance we can get ZW to accept a login like this?

[Saq Imtiaz]

Bob:
I've made some progress but need to do some more testing. So ignore my previous message until further notice.
Cheers,
Saq

[Saq Imtiaz]

Bob, CoolCold:

Ok, I have made significant progress. While there are still a lot of details to figure out, I have managed to get saving tiddlers to ZW working. The same code should work with ccT, once ccT has the ability to fetch single tiddlers via a GET request.

Bob:

•  it seems like ZW wont save a tiddler unless it receives an id.
  This works:
  "action=save&id=title&title=title&body=text&tags=tag&modified=modifed&created=created"
  This doesnt:
  "action=save&title=title&body=text&tags=tag&modified=modifed&created=created"
• Regarding authentication, if the user is already logged in it works. But I plan to log the user in each time using a POST,identical to how logins work in ZW. It seems the most practical approach.
  

CoolCold:

• ccT needs to accept and save tiddlers from POSTS like:
  "action=save&id=title&title=title&body=text&tags=tag&modified=modifed&created=created&overwrite=0&username=username&password=password"
  It can of course ignore the id,modified and created.
• Also, as we discussed before, we need to be able to fetch single tiddlers:
  "?action=get&id=title"
• Would it all be possible to do a POST that returns all tiddler titles as an array? ZW returns something like that when the user logins in... and if we use that to check if the tiddler exists, it will save frequent trips to the server.
  Something like this maybe: "?action=contents"
  
• Regarding authentication, we should be able to get it working without the need for cookie based authentication, so you dont need to worry about that for now.
  However, I am curious, does ccT have any option for logging in via a POST?
  
• Once you've got that working, if you could please update the test site and let me know,  that would be great.

Thanks for all your help guys!
Cheers,
Saq

[Saq Imtiaz]

On 9/16/06, Saq Imtiaz <lew...@gmail.com> wrote:

• Would it all be possible to do a POST that returns all tiddler titles as an array? ZW returns something like that when the user logins in... and if we use that to check if the tiddler exists, it will save frequent trips to the server.
  Something like this maybe: "?action=contents"

Oops, an object would be better than an array.
Here is what ZW returns on login:

if(typeof zw == "undefined") var zw = {};
zw.loggedIn = true;
zw.anonEdit = false;
zw.ziddlyPath = 'http://ziddlywiki.com/TiddlySnip/index_html';

zw.isAdmin = false;
zw.latestTiddler = 115841384259;
zw.username = 'lewcid';
version.extensions.ZiddlyWiki = '4';
zw.tiddlerList = {
    "GettingStarted": "872.14225.24678.51490",

    "GettingStarted23": "872.14221.20626.58845",
    "GettingStarted234": "872.14224.28306.14182",
    "GettingStarteds": "872.14215.63862.21538",
    "Test": "
872.14046.45145.26129",
};

 

So I can run an eval and use zw.tiddlerList to check if a tiddler exists already.....
Cheers,
Saq

[google....@dfgh.net]

hi,

I will work on it the coming week.

• ccT needs to accept and save tiddlers from POSTS like:
  "action=save&id=title&title=title&body=text&tags=tag&modified=modifed&created=created&overwrite=0&username=username&password=password"
  It can of course ignore the id,modified and created.

This will be implemented

• Also, as we discussed before, we need to be able to fetch single tiddlers:
  "?action=get&id=title"

 This will be implemented

• Would it all be possible to do a POST that returns all tiddler titles as an array? ZW returns something like that when the user logins in... and if we use that to check if the tiddler exists, it will save frequent trips to the server.
  Something like this maybe: "?action=contents"
  

How should the return be like? Should I put all tiddler titles each in a new line? or put them as variable in a script?

• Regarding authentication, we should be able to get it working without the need for cookie based authentication, so you dont need to worry about that for now.
  However, I am curious, does ccT have any option for logging in via a POST?

Yes, this is what I originally planned
 

• Once you've got that working, if you could please update the test site and let me know,  that would be great.

I'll let you know when I have update the site.

Thanks for all your help guys!
Cheers,

Saq

Cheers,
CC

[Saq Imtiaz]

On 9/16/06, google....@dfgh.net <google....@dfgh.net > wrote:

• Would it all be possible to do a POST that returns all tiddler titles as an array? ZW returns something like that when the user logins in... and if we use that to check if the tiddler exists, it will save frequent trips to the server.
  Something like this maybe: "?action=contents"
  

How should the return be like? Should I put all tiddler titles each in a new line? or put them as variable in a script?

 Hmm. It doesnt really matter, whatever is easier for you, I will have to do some postprocessing anyway so I can be flexible. So anything that I can easily convert into an array will be fine.
Cheers,
Saq

[Bob McElrath]

Saq Imtiaz [lew...@gmail.com] wrote:
> On 9/15/06, coolcold <google....@dfgh.net> wrote:
> >
> >
> > Hi guys,
> >
> > Sorry for late reply. Answers below
> >
> > > Information needed:
> > >
> > > 1. Does ccT need arguments for tiddler created and tiddler modified?
> > ccT don't need these two arguement. I can take both though, just a line
> > of code change really.
>
> Ideally I feel this should be handled on the server-side.
> Currently ZW requires these arguments, but ccT does not. I don't have a
> problem either way. TiddlySnip can provide these, but you guys needs to
> decide which one of you has to change. ;)

My thinking here in proposing "unification" is to unify the javascript
necessary to use a server-side. This could then be a ServerSidePlugin
that we could distribute, and the plugin wouldn't care whether it was
using ccT or ZW. This plugin would have the bare minimum of
functionality that CC and I would probably extend. I'm not really
proposing that ccT/ZW functionality be identical. Just that there be a
common subset.

> > 2. can ccT provide the ability to get single tiddlers like ZW does?
> > > (http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc
> > > )
> > Not implemented yet. Would you like it in regular TW form with a single
> > div in the storeArea? Or just the requested tiddler in div form?
>
>
> This is probably the most important part. If we can get this working, it
> will help with the error codes and the overwrite too.
> At this time, I dont have a personal preference for the format of the
> tiddler, but it makes sense to use the same as ZW.
>
> Have a look at:
> http://www.ziddlywiki.com/doc?action=get&id=TiddlyDoc
> and compare with: http://www.ziddlywiki.com/doc

I have been thinking that the "get" function really should return a div.
The reason is that the div contains all the information in the tiddler
that I'm now essentially sending in a custom format. (modified,
modifier, etc) Plus, if it's put in a div you can also send the fields.
As things stand now I'd have to extend the format of the data sent by
the "get" method to handle fields.

So, in the near future I will change "get" to return a div. I think ccT
should probably do the same.

[Saq Imtiaz]

On 9/17/06, Bob McElrath <bob.mc...@gmail.com> wrote:

> >    2. can ccT provide the ability to get single tiddlers like ZW does?
> > > (http://doc.tiddlywiki.org/?action=get&id=TiddlyDoc
> > >    )
> > Not implemented yet. Would you like it in regular TW form with a single
> > div in the storeArea? Or just the requested tiddler in div form?
>
>
> This is probably the most important part. If we can get this working, it
> will help with the error codes and the overwrite too.
> At this time, I dont have a personal preference for the format of the
> tiddler, but it makes sense to use the same as ZW.
>
> Have a look at:
> http://www.ziddlywiki.com/doc?action=get&id=TiddlyDoc
> and compare with: http://www.ziddlywiki.com/doc

I have been thinking that the "get" function really should return a div.
The reason is that the div contains all the information in the tiddler
that I'm now essentially sending in a custom format.  (modified,
modifier, etc)  Plus, if it's put in a div you can also send the fields.
As things stand now I'd have to extend the format of the data sent by
the "get" method to handle fields.

So, in the near future I will change "get" to return a div.  I think ccT
should probably do the same.

Hey Bob, either or is fine by me. I didnt suggest a div so as to not force a change on your end. Though, if the get returns a div, shouldnt the POST also use a div in interests of some symmetry?

Overall, I've got things figured out on my end, and am just waiting for the serverside implementations to be finalized so I can tweak the code accordingly.

Cheers,
Saq


PS: the idea of a serverside plugin does sound terrific!

[Bob McElrath]

Saq Imtiaz [lew...@gmail.com] wrote:
> Bob, CoolCold:
>
> Ok, I have made significant progress. While there are still a lot of details
> to figure out, I have managed to get saving tiddlers to ZW working. The same
> code should work with ccT, once ccT has the ability to fetch single tiddlers
> via a GET request.
>
> Bob:
>

> - it seems like ZW wont save a tiddler unless it receives an id.

> This works:
> "action=save&
> id=title&title=title&body=text&tags=tag&modified=modifed&created=created"
> This doesnt:
>
> "action=save&title=title&body=text&tags=tag&modified=modifed&created=created"

Ah thanks, this is a bug and I have fixed it now.

I will make modified and created optional arguments too (they will be
set by the current time).

> - Regarding authentication, if the user is already logged in it works.

> But I plan to log the user in each time using a POST,identical to how logins
> work in ZW. It seems the most practical approach.

The username and password arguments to XMLHTTPRequest.open() you asked
about seem, as far as I can tell, to be HTTP Basic authentication. So,
this should work with ZW. I still have to sort out the HTTP Basic vs.
cookie situation. (Right now I want to keep HTTP Basic as the main
login mechanism, but that's NOT what's used at zw.com) With cookies I
can also describe for you how to create the login cookie (it's a base64
encoded username/password, I think).

[Bob McElrath]

Udo Borkowski [Udo.Bo...@gmx.de] wrote:
> I haven't followed this discussion in detail, but just a little note:
>
> >Sound like its in the form
> >title
> >body
> >modifier
> >modified
> >created
> >tag
> >If you want, I can put something together similar to this.
> >
> You may consider already planning to support extended fields (metadata).
> Therefore it would probably be a good idea to use the same names as the
> fieldnames in 2.1. Esp. "body" is called "text" and "tag" is called "tags".

As I mentioned in another mail, I think we should change this to a div
(identical to as it would appear in the store), which can contain the
extended fields.

[Saq Imtiaz]

On 9/17/06, Bob McElrath <bob.mc...@gmail.com> wrote:

>    - Regarding authentication, if the user is already logged in it works.
>    But I plan to log the user in each time using a POST,identical to how logins
>    work in ZW. It seems the most practical approach.

The username and password arguments to XMLHTTPRequest.open() you asked
about seem, as far as I can tell, to be HTTP Basic authentication.  So,
this should work with ZW.  I still have to sort out the HTTP Basic vs.
cookie situation.  (Right now I want to keep HTTP Basic as the main
login mechanism, but that's NOT what's used at zw.com)  With cookies I
can also describe for you how to create the login cookie (it's a base64
encoded username/password, I think).

What about logging in via a POST XMLHttpRequest?
This works well for the test site you setup for me:
"action=login&__ac_name=username&__ac_password=password";

This seems to be identical to how the macro used to login from ZW, so it should work with cookie and HTTP Basic authentication. If that's the case, it might be the easiest way of handlig logins.

If there is some reason we shouldnt go down that road, just let me know. Creating login cookies etc shouldnt be a problem.

Cheers,
Saq

[Bob McElrath]

Saq Imtiaz [lew...@gmail.com] wrote:
> Hey Bob, either or is fine by me. I didnt suggest a div so as to not force a
> change on your end. Though, if the get returns a div, shouldnt the POST also
> use a div in interests of some symmetry?

Yes.

That would also get rid of all the arguments to the "save" function.

http://your.site.here/?action=save

And content of the POST would then not be www-urlencoded, but the plain
text div. This would mean that TS would need to set the "created" and
"modified" fields.

> Overall, I've got things figured out on my end, and am just waiting for the
> serverside implementations to be finalized so I can tweak the code
> accordingly.

I'll be back home on Monday, perhaps later this week I can put some more
work into ZW.

> PS: the idea of a serverside plugin does sound terrific!

Good! We should have some more serious discussions in that direction.

[Bob McElrath]

Saq Imtiaz [lew...@gmail.com] wrote:
> On 9/17/06, Bob McElrath <bob.mc...@gmail.com> wrote:
> >
> >
> > > - Regarding authentication, if the user is already logged in it
> > works.
> > > But I plan to log the user in each time using a POST,identical to how
> > logins
> > > work in ZW. It seems the most practical approach.
> >
> > The username and password arguments to XMLHTTPRequest.open() you asked
> > about seem, as far as I can tell, to be HTTP Basic authentication. So,
> > this should work with ZW. I still have to sort out the HTTP Basic vs.
> > cookie situation. (Right now I want to keep HTTP Basic as the main
> > login mechanism, but that's NOT what's used at zw.com) With cookies I
> > can also describe for you how to create the login cookie (it's a base64
> > encoded username/password, I think).
>
>
> What about logging in via a POST XMLHttpRequest?
> This works well for the test site you setup for me:
> "action=login&__ac_name=username&__ac_password=password";

That will work fine. Also the name and password can (and maybe should)
be omitted. Any request to the login script (as above) will trigger the
browser's HTTP Basic and show the browser's login dialog. I do send it
in case the user is using cookies, but it's ignored if the user is using
HTTP Basic. (And will always work with HTTP Basic even if the user has
cookies enabled)

> This seems to be identical to how the macro used to login from ZW, so it
> should work with cookie and HTTP Basic authentication. If that's the case,
> it might be the easiest way of handlig logins.
>
> If there is some reason we shouldnt go down that road, just let me know.
> Creating login cookies etc shouldnt be a problem.

Yes this works on zw.com, but setting up the cookie-based auth is an
extra step that I don't think most users are doing with their ZW sites.
They are all using HTTP Basic instead. I'm not sure how to set up a
test site for you that uses the usual HTTP Basic, but as soon as I
figure it out I'll do that...

[Saq Imtiaz]

On 9/17/06, Bob McElrath <bob.mc...@gmail.com> wrote:

Saq Imtiaz [lew...@gmail.com] wrote:
> Hey Bob, either or is fine by me. I didnt suggest a div so as to not force a
> change on your end. Though, if the get returns a div, shouldnt the POST also
> use a div in interests of some symmetry?

Yes.

That would also get rid of all the arguments to the "save" function.

http://your.site.here/?action=save

And content of the POST would then not be www-urlencoded, but the plain
text div.  This would mean that TS would need to set the "created" and
"modified" fields.

Thats not a problem. TiddlySnip already creates a  proper tiddler div for local files, so if anything that reduces the work on my end.

CoolCold: you might want to take this into account before you start work. Sorry about all the changes mate. But most of these suggestions will have far greater benefits for the serversides than just compatibility with TiddlySnip

Cheers,
Saq

[google....@dfgh.net]

Hi,

So should I return a div or the same way as ZW now?

As for unifying the plugins, it does sound like a great idea but somehow I have a gut feeling that it could be quite difficult though. Definitely need more discussion on it.

The changes are more or less completed. Just let me know whether you want div or same as current ZW and I can make the changes to the test site.

Let me know if I have missed anything

CC

[Saq Imtiaz]

On 9/17/06, google....@dfgh.net <google....@dfgh.net > wrote:

Hi,

So should I return a div or the same way as ZW now?

Hi CoolCold,

If it's not too much trouble, return the  same as ZW for now. That way I can get started on coding on my end. Then when Bob changes ZW to return a div, you could update ccT to do the same, and I can update TiddlySnip.

If that seems like too much work, then just return a div, and I'll wait for Bob to make the same change to ZW before I can continue.

Thanks CoolCold!
Cheers,
Saq

[google....@dfgh.net]

Hi,

Done.

CC

[Saq Imtiaz]

On 9/17/06, google....@dfgh.net <google....@dfgh.net > wrote:

Hi,

Done.

Thanks CoolCold! I havent  looked at  ccT so far, only ZW.  So tomorrow I'll get started on the ccT test site and I'll let you know how it goes. I dont anticipate any major problems, but we might need to make a few small changes here and there..... but I think first I'll just have to take a moment tomorrow to get used to how ccT works, as I've never used it before.
Cheers,
Saq

[Saq Imtiaz]

CoolCold:

I think I am missing something basic here, I cant seem to be able to do a GET for either a single tiddler or all the tiddler titles.... what arguments have you used?

I'm doing a GET with url http://members.lycos.co.uk/cctiddly/TiddlySnip/index.php

and arguments: "action=get&id=Test" to get the tiddler Test and that doesnt work.

For the titles of all tiddlers I tried this argument:

"action=contents" but that doesnt work either

Any suggestions?
Cheers,
Saq

[google....@dfgh.net]

Hi,

Given that it's my first time to use some of the functions, I'll apologise if it is very buggy. Please let me know of any problem you've found and I'll sort it out asap.

I've forgot to include the details of variables. Here are the HTTP return result

code:
            200: ok - content updated
            201: created - content created
            204: no content - tiddler not found
            401: unauthorized - username password error
            403: forbidden - no privilege
            405: Method Not Allowed - error for duplicated tiddler without overwrite
            406: Not Acceptable - error for empty title or body
            500: Internal Server Error - unknown error

I don't know what you have decide to do with overwrite but I set it to [1 = overwrite, 2 = append]

action =
"TiddlySnip" - save
"TSgetAll" - get all tiddler title
"TSget" - get a particular title

[google....@dfgh.net]

Hi,

Try the url
http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php
with post variable
action=TSget&title=GettingStarted

I started to worry the adverts from lycos might render it unusable. I'll try to set one up on sf.net and email you later.

CC

On 17/09/06, Saq Imtiaz - lew...@gmail.com <+google+coolcold+1ebfce80b2.lewcid#gmail.com@ spamgourmet.com> wrote:

[Saq Imtiaz]

On 9/17/06, google....@dfgh.net <google....@dfgh.net > wrote:

Hi,

Given that it's my first time to use some of the functions, I'll apologise if it is very buggy. Please let me know of any problem you've found and I'll sort it out asap.

I've forgot to include the details of variables. Here are the HTTP return result

code:
            200: ok - content updated
            201: created - content created
            204: no content - tiddler not found
            401: unauthorized - username password error
            403: forbidden - no privilege
            405: Method Not Allowed - error for duplicated tiddler without overwrite
            406: Not Acceptable - error for empty title or body
            500: Internal Server Error - unknown error

I don't know what you have decide to do with overwrite but I set it to [1 = overwrite, 2 = append]

Thanks CC, no wonder  I wasnt getting anywhere without those.:) 

action =
"TiddlySnip" - save
"TSgetAll" - get all tiddler title
"TSget" - get a particular title

 

Im off to bed for today, so I'll let you know how it goes tomorrow.
However, a few quick points.
Could we try to use the same actions that ZW does? Because otherwise TiddlySnip cannot use the same code for both serversides.

for save, can the action just be save?
and for TSget, ZW does action=get&id=tiddlertitle
can we use the same?

Also, for the url, is it possible to use just the site url, without the msghandle.php?
So http://members.lycos.co.uk/cctiddly/TiddlySnip/ and not http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php

[Saq Imtiaz]

On 9/17/06, google....@dfgh.net <google....@dfgh.net > wrote:

Hi,

Try the url
http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php
with post variable
action=TSget&title=GettingStarted

I started to worry the adverts from lycos might render it unusable. I'll try to set one up on sf.net and email you later.

Ok, I tried that and it works. Lycos does inject some javascript, but for testing it should be fine. 

For getting the contents and single tiddler, isnt it better to do a GET? and for saving tiddler a POST? That seems to be the standard for these things. A GET to receieve data from server, a POST to send data to server.

Here is an inline script you can tweak and use in a TW to test:

<script label="run">
function downloadTW()
{
    netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
    var url = "http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php";
    var data = "action=TSget&title=GettingStarted";
    var request;
    request = new XMLHttpRequest();
    request.open("POST", url, true);
    request.onreadystatechange = function ()
        {
        if (request.readyState == 4) {
            if( request.status == 200) {

                alert(request.responseText);
            }
            else
                alert("request.responseText");
        }
    };
    request.setRequestHeader ('Content-Length',data.length);
    request.setRequestHeader('Content-type','application/x-www-form-urlencoded');
    request.send(data);
}
downloadTW();
</script>

Take your time with all of this, and thanks.
Cheers,
Saq

[google....@dfgh.net]

Hi,

Im off to bed for today, so I'll let you know how it goes tomorrow.
However, a few quick points.
Could we try to use the same actions that ZW does? Because otherwise TiddlySnip cannot use the same code for both serversides.

-Done. Now use save, get and content for save TS, get a title and get all titles (separate by linebreaks)

for save, can the action just be save?
and for TSget, ZW does action=get&id=tiddlertitle
can we use the same?

-now get will use action=get&id=tiddlertitle
but for save, it is still action=save&title=tiddlertitle&...
you will need to pass in username and password for all action for accurate result

Also, for the url, is it possible to use just the site url, without the msghandle.php?
So http://members.lycos.co.uk/cctiddly/TiddlySnip/ and not http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php

-unfortunately, this is not possible at the moment since index.php does not handle any of the changes. Is it possible to let the user put this in as a variable when filling in the url? This would also the user to pick different config file to use since ccT support hosting multiple TW.

Have a good night.

CC

PS I have email you the link to another test site in case the lycos one doesn't work properly.

[Saq Imtiaz]

On 9/18/06, google....@dfgh.net <google....@dfgh.net > wrote:

Also, for the url, is it possible to use just the site url, without the msghandle.php?
So http://members.lycos.co.uk/cctiddly/TiddlySnip/ and not http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php

-unfortunately, this is not possible at the moment since index.php does not handle any of the changes. Is it possible to let the user put this in as a variable when filling in the url? This would also the user to pick different config file to use since ccT support hosting multiple TW.

Ok, thanks for all the changes, it seems everything is working.... its not an ideal situation with the msghandle.php, but I will manage. For now I dont think it will be possible to use the exact same code for both serversides. I will let the user choose whether they are using ccT or ZW.

However, I would like to make one last request for a change.
Currently for getting a single tiddler or getting the contents, I have to do a POST

What I would like to do is do a GET.
For a single tiddler I would do a GET to url:
http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php?action=get&id=GettingStarted
And for the contents:
http://members.lycos.co.uk/cctiddly/TiddlySnip/msghandle.php?action=content

If this is a problem we can use it the way it is now, but it makes sense to make this change.
A GET request to get data from the server, and POST for saving to the server.

Cheers,
Saq

[google....@dfgh.net]

I'll make the changes tonight. If using index.php is really necessary, I think I can put the codes there too but the codes would look messy. I'll see what I can do with it.

CC

[Saq Imtiaz]

On 9/18/06, google....@dfgh.net <google....@dfgh.net > wrote:

I'll make the changes tonight. If using index.php is really necessary, I think I can put the codes there too but the codes would look messy. I'll see what I can do with it.

Thanks CC. The change to using index.php isnt necessary,  but it will mean that the API for both ZW and ccT will be almost identical.... and I should be able to use the same code for both. Which means that end users can just select that they have a serverside TW, they dont need to specify which kind.

So it isnt necessary, but it would be nice. If it gets too messy, just leave it.
Cheers,
Saq

CC

[coolcold]

Hi,

Since you will need the username and password for GET request, would
you like to include that in POST or GET? I personally prefer POST for
security reasons (if it would appear in some sort of history). I don't
mind to use any of them, code wise.

CC

[Saq Imtiaz]

The GET requests are not  cached, so there shouldnt be a problem  in terms of security. So let's just include the password and username in each request. GET for tiddler and content, and POST for save.

Saq

CC

[google....@dfgh.net]

done. content and get uses GET, save uses POST

CC