Cory Helfrich wrote:
Hi!
>> Do we have someone on the list that actually plays more
>> seriously by email and could give me a helping hand about
>> what is needed in that area?
>
> I don't know if you can call any chess I play "serious",
> but I do play at IECC.
Well, I think it's not necessary for you to be the world
champion in email chess ;) That you're familiar with IECC
will surely help alot.
> The IECC's instructions on time controls are (needlessly)
> complicated. The time controls are based on reflection
> time. Your reflection time for a move is the integer
> number of days between the date your opponent's move was
> available on your email server and the date you send your
> reply move. Note that these are dates, not times.
Ok, thats what was also my impression from the pages, that
it's only about days.
> For example, if my server receives my opponent's move at
> 11:59 pm and I send my reply two minutes later, I am
> charged one day of reflection time.
Ah! Hence, if I stamp the incoming mail 06/01/2008 and the
outgoing mail also to 06/01/2008 I'd have to add one day to
the reflection time count.
[...]
> Because of the above and because, in my experience at the
> IECC, time controls are so rarely an issue, I recommend
> spending your talents on other improvements (or at least
> not building the email manager around the IECC time
> controls. I suggest including a reflection time column
> (with manual entry) in the present email manager.
Ok, from your points I see that it is just not really
possible to do all of this automagically. Now, I'll just
tell you what I did so far.
If you receive a mail and sync it in using the current CC
code it will stamp the reception time like you can do it
with scids current email manager by just "Time - Received
today". If you send a mail from current CC window a similar
stamp will be added for "sent move today". I wondered why
Shane left all this to manual handling but as I understand
you, there is just no real possibility beyond that. Now,
I could read out these time stamps (you can also edit them
as usual by the current email manager, btw.) and calc a
difference to be shown in the CC windows columns as
reflection time.
>> Mainly they do not allow for additional metadata within
>> the header or commentary code within the body. Actually I
>> need some additional metadata fields to allow for
>> automatic synchronisation and I modeled this after
>> xboards cmail function. The "old" email manager though
>> still allows for the easy creation of the rudiments
>> required by these two organisations.
>
> I am not sure what you mean by metadata.
Sorry, librarians talk. All data describing the game. Ie.
the whole PGN header.
> As long as the complete move list is transmitted as plain
> text in the body of the email message, I think this will
> meet the IECC requirements.
This is no problem. My own email chess code however works a
bit more automatic than the old scid code and it is modeled
after cmail (probably nobody really knows that though it
comes for ages together with xboard). That is I just extend
the PGN header in completely PGN conformal way. This looks
like this:
[Event "Email correspondence game"]
[Site "NET"]
[Date "2008.01.23"]
[Round "-"]
[White "xxxxxx, yyyy"]
[Black "zzzzzz, aaaa"]
[Result "*"]
[whiteCountry "ger"]
[blackCountry "ger"]
[WhiteNA "[EMAIL PROTECTED]"]
[BlackNA "[EMAIL PROTECTED]"]
[Mode "EM"]
[CmailGameName "SomeUniqueKey"]
whiteCountry/blackCountry where recently introduced in
SchmingMind for xfcc, they are not really important, they
just allow to show the proper flags.
WhiteNA/BlackNA hold the mail addresses of both opponents.
Its the way cmail exchanges them, and these fields are
available in Xfcc as well (though optional there).
Mode is actually used to distingish between Xfcc and eMail.
EM is the code used by cmail again.
CmailGameName is pure cmail in principle, but I also use it
for Xfcc. It is just a unique identifier for the game. This
one is vitally important for my CC code as it is used to
find the game within the current database.
From this you can see, that the whole thing is pure PGN also
containing the whole move list of course, but that I have
additional fields, that are required. As far as I understand
IECC they should not be there for trasmission to the
archives, ok, there one can strip them. I don't know wether
they disturb anything in gameplay. Anyway, as soon as you
drop WhiteNA/BlackNA and CmailGameName my code will not know
how to handle an email game.
As a last point, where I'm not sure about IECC: to transmit
the PGN in question I create an attachment of type
application/x-chess-pgn. It is not sent as inline text but
as a real attachment. This is actually more convenient as
you can just associate this type with whatever application
you want and click on it in your mailer, whereas inline
transmission would require the mailer to pipe the body
through an external program. Of course mail programs like
mutt allow for this, but all this GUI stuff of these days
doesn't know a thing about it.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
