PDN Question

[Michael S. Sanders]

Gulp! Welp, here's the 1st. of my silly newbie questions...

Which set of <specifcations> is presently the most commonly used? <PDN> or <PDN2>

Thanks!

[matthewkooshad]

There used to be some write up about this on triplejump.net forum; it seems their site is down now, though.

Hans, Murray (nem), or Martin (cb) probably can answer this for you. Each of their sites can be found in links section of my site if an answer doesn't pop up here for you.

[Jason Solan]

Murray has the pdn2 (current) specification on his site:
http://nemesis.info/pdn2.txt

and i found this useful tidbit on wikipedia
http://en.wikipedia.org/wiki/Portable_Draughts_Notation

its been a while since i've worked with it, but i believe pdn2 is an extension of pdn and an attempt to clean things up a bit and make things more clear as the original pdn allowed for too much to be interpreted

...anyone is welcome to correct me

EDIT: In my applications i've always gone off of pdn2 specifications

[Michael S. Sanders]

Matt & Jason, thanks for the heads up guys!

[Jason Solan]

There is another document that i remember about valid PDN.
Its open source and written by Martin Fierz and Peter Chiochetti. It was used in Peters open source checkers program for linux called xcheckers which was similar to Checkerboard and used and older version of the Cake engine.

I can't find the document now, but i came acrossed it a few weeks ago and wished i had read it when i wrote my PDN stuff in PHP. In fact i may rewrite my PHP algorithm if i find that document again.

Ahh i found it, its called pdntool. Its designed for linux, but i'm relatively sure its written in C.

http://arton.cunst.net/xcheckers/

[Michael S. Sanders]

Hey nifty! Built a PDN parser huh? Sounds interesting, I'm knocking around the idea of building a database/app (Win32) for checker problems/puzzles. Export to PDN no biggie, import... dunno just yet.

[murray]

I hope PDN2 will be adopted. The specification I wrote was with input from all the major checkers programmers so it is what everyone wanted.

The problem with PDN1 was that it was so loosely defined that it caused problems with interoperability between different programs. PDN2 tries to correct that.

However the spec still needs more work before it's in a good state.

[Michael S. Sanders]

Hello Murray, nice to meet you buddy.

Re: However the spec still needs more work before it's in a good state.

Oh I dunno, looks pretty good from my vantage point. =)

If I do get around to writing my checker app, likely I'll extend your specs by one tag/field/cell (not sure of the nomenclature used just yet, please forgive). I'd like to include the ability to leverage remote resources. Some context is in order it seems, please allow me to explain by way of example:

Code: Select all

[Resource] "x:\path\3rd_Party_annotation.doc"

[Resource] "http://mattswebsite/moredetail.php"

[Resource] "c:\path\Nemesis\Nemesis /args famous_game.ext"

The ShellExecute() API would work very well here under Windows as one could exploit file associations. I belive similar macros are available under Mac & Linux, etc.

Imagine this scenario...

You and I engage in a game and I loose - you have (say) 20+ years of experience

Matt cobbles together a flash based play-by-play commentary of the game - he has 15 years+ of experience.

Finally, Alex adds his commentary re: the game - he has 25+ years of experience (these numbers are for example only of course) so,

Benefits:

+ 60yrs. cumulative checker experience is never more than a click away

+ Remote commentary will stay up to date with each new iteration of the remote resource

+ Packs a whole lotta ahem 'wallop' (added extensibility) for the price of an additional cell, as 'Resource' could be defined on a case-by case basis sort of like XML...

[murray]

The ShellExecute() API would work very well here under Windows as one could exploit file associations.

Hi Michael, it's an interesting idea I'll have to give some more thought to.

The major problem with this of course, is one of security. If PDN files had this kind of power, it opens them up to abuse. If a PDN reader simply trusted any PDN file it opened (and accessed all resources using ShellExecute) you would be opening up your computer to malicious harm from hackers.

The usual way around this is to either limit the type of resource that the PDN reader can open to those types that are relatively harmless, or incorporate some kind of trust signing to PDN files.

Either way it's a lot of work and I'd be surprised if there was much take-up of this from the PDN reader community because of the work involved. There is also the risk of lawsuits etc if a PDN reader becomes responsible for trashing a computer.


Of course there is nothing stopping you from adding a feature like this to your PDN reader - Just be wary of the pitfalls. With power comes responsibility!

[Michael S. Sanders]

Howdy Murray, glad you chimed in with your thoughts, thank you kind sir. I'll kindly rebutt them in order.

The major problem with this of course, is one of security. If PDN files had this kind of power, it opens them up to abuse. If a PDN reader simply trusted any PDN file it opened (and accessed all resources using ShellExecute) you would be opening up your computer to malicious harm from hackers.

No more or no less than any other piece of code I'd argue. In my vision of this implementation, the resource string is visible and can be modified as well by the end user as they so need.

The usual way around this is to either limit the type of resource that the PDN reader can open to those types that are relatively harmless, or incorporate some kind of trust signing to PDN files.

An interesting idea for sure. Does Nemesis implement any trust authentication scheme? I'm gussing you use Winsock for your remote stuff. While I can fully appreciate your concern with respect to malicious code, my extension does nothing more than use existing shell associations. No more, no less. In fact, its the equivalent of clicking a file in layman's terms.

Either way it's a lot of work and I'd be surprised if there was much take-up of this from the PDN reader community because of the work involved. There is also the risk of lawsuits etc if a PDN reader becomes responsible for trashing a computer.

A lot of work? Law suits? Huh? Good gravy man, I'm sorry friend but I don't buy this...

1. It's not alot of work:

Code: Select all

void MyResource (char *Resource)
{
  ShellExecute(0,"open",Resource,0,0,1);
}

2. Those disagreeing with the extension can simply ignore it without any problems at all. No fuss, no muss.

3. Via your website url http://www.nemesis.info/techspecs.htm

'Nemesis is very closely integrated with the Internet. Built on top of Microsoft Internet Explorer, Nemesis works seamlessly with browsing the net which makes Internet game playing easier and more enjoyable. Also updates and downloads are available at the click of a button...'

Earlier you had stated: 'The major problem with this of course, is one of security.'

This is close to the same thing as I'm planning.

!?!

On one hand you vigurously dissuade me from this approach and yet, on the other, you use the same technology. Murray please clarify your position.

Once again thanks and best regards.

Edit: Please allow me to soften my response here, on a 2nd reading, seems to impart a brusque feel that I had'nt intended (Texan talk). Your advice is well taken actually, just somewhat of a curveball I guess. No biggie. =)

[hans]

Ok, I'm a bit late on this one but PDN2 is what I try to adhere to when creating pdn-files.

And on the resource stuff: as long as it's definition is OS-independent I do not really care, my parsers ignore everything they don't understand .

I have been meaning to ask you for a while Murray. Have you never regretted tying Nemesis so close to IE? It is the most commonly used browser still but it certainly is inferiour to Opera and Firefox these days.[/b]

[murray]

Michael, you aren't taking the security side of things seriously enough.

No more or no less than any other piece of code I'd argue. In my vision of this implementation, the resource string is visible and can be modified as well by the end user as they so need.

The major difference here is, when a user clicks on a file, they are repsonsible for clicking on that file and the consequences. When a user opens what appears to be a harmless checkers PDN document and it then reformats their hard drive (extreme case but possible with this kind of extension), then whose fault is it?

In the day and age where you get sued for selling coffee that is too hot, I know I wouldn't want to implement this kind of stuff in my pdn viewer without a layer of protection fot the user - IMO it is folly not to have some kind of security here.

Having thought some more about it, this is the kind of thing I think is acceptable.

1) When a user opens a PDN document, the PDN viewer first scans the entire document. If any resource tags are found, the viewer pops up a query to the user interactively saying something like:

Code: Select all

"The PDN document you are trying to open contains external references that could potentially harm your computer. If you are sure the PDN comes from a trusted source, click continue, otherwise cancel."

(Perhaps a "details..." button can show all the resource references?)

This gets round any liability issues from the point of view of the PDN viewer author.

Also to make things more user-friendly there should be a security level on the PDN viewer. High - Ignore external resources, open the PDN without them. Medium - Always query the user as shown above. Low - Always trust all PDN docs. The user can set the security level to what they want, to avoid always having to answer security questions - if that is what they really want!

Does Nemesis implement any trust authentication scheme

No - because none is necessary. At the moment Nemesis cannot run malicious code or be abused by hackers.

1. It's not alot of work:

Code:
void MyResource (char *Resource)
{
ShellExecute(0,"open",Resource,0,0,1);
}

That is not a lot of work, but I was thinking of the extra work to put on a security layer too. However the suggestion above isn't a massive amount of effort.

On one hand you vigurously dissuade me from this approach and yet, on the other, you use the same technology. Murray please clarify your position.

All I am saying is, great idea but beware the pitfalls! Just trying to help you out buddy, feel free to disagree!

And on the resource stuff: as long as it's definition is OS-independent I do not really care, my parsers ignore everything they don't understand

Hi Hans, I think other platforms can cope with Michael's suggestion as they will all have some way of associating an application with a file? I haven't tried to write a PDN parser on Mac Linux or Unix yet so I'm not really qualified - need more input from an expert in that area.

Have you never regretted tying Nemesis so close to IE? It is the most commonly used browser still but it certainly is inferiour to Opera and Firefox these days

Yes the other browsers are more efficient in their use of hardware resources and are better designed with regard to security. IE was a good choice at the time and still is, because it's good enough for the job, and handles well what I want it to do. I guess it's a case of using the tools that you are familiar with too, and I really didn't want to go through the learning curve of Java or C++ to handle the graphical side of things. Those who use Nemesis are probably not aware they are using internet explorer anyway! It looks just like any other program.[/b][/code]

[Michael S. Sanders]

Hi Murray. When and if the app in question is born, I'll let community consensus be the judge. Thanks for your input.

[Michael S. Sanders]

Re: Michael, you aren't taking the security side of things seriously enough.

Via: http://www.nemesis.info/help/features.htm

'All versions of Nemesis contain the following:

XML file format supported; Documents can be opened from the Internet or from local files'

Devil take the hindmost buddy, I press forward still.

[murray]

'All versions of Nemesis contain the following:

XML file format supported; Documents can be opened from the Internet or from local files'

That's true - but only xml that conforms to the XSD I have defined in http://www.nemesis.info/nemesis.xsd

So this is safe - it does not reference anything insecure.