Project

General

Profile

Actions

Bug / Feature #211

closed

Source and documentation

Added by spale about 14 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Documentation
Target version:
Start date:
09 November 2010
Due date:
% Done:

100%

Estimated time:
Request Type:
Feature Request
Affected Program:
None
Affected Users:
Developers

Description

I'd like to implement a client. Therefore I request the source code of the current client and server implementations and the documentation of the client-server protocol.

Actions #1

Updated by dergringo about 14 years ago

I'm not part of this project, but there is a subversion repository which seems to hold the stuff you requested: https://dev.piratenpartei.ch/svn/pi-vote

Actions #2

Updated by spale about 14 years ago

Yes Philipp, but how so I SVN on this?

Actions #3

Updated by Exception about 14 years ago

The documentation isn't progressed that far mostly because the protocol or rather the message/containers used are quite complex.

Actions #4

Updated by dergringo about 14 years ago

Pascal Gloor wrote:

Yes Philipp, but how so I SVN on this?

svn co https://dev.piratenpartei.ch/svn/pi-vote

Actions #5

Updated by Exception about 14 years ago

  • Category set to Documentation
  • Status changed from New to 2
  • Assignee set to Exception
Actions #6

Updated by Exception almost 14 years ago

  • % Done changed from 0 to 50
Actions #7

Updated by Exception almost 14 years ago

A version of the Pi-Vote Protocol documentation can now be found in the files section.

Actions #8

Updated by spale almost 14 years ago

I had a quick look at the doc are something 'popped up' in front of my eyes. In point 1.2 "Example", I see length and data. Length is an int32 host encoded, not in network byte order. Is this a mistake or done on purpose? RFC791 (IPv4) is pretty clear about this: "The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English.", meaning most significant octet is 'left' and less significant octet is 'right'.

http://en.wikipedia.org/wiki/Endianness#Endianness_in_networking

Actions #9

Updated by Exception almost 12 years ago

  • Tracker changed from 3 to Bug / Feature
  • Status changed from 2 to Needs Work
Actions #10

Updated by Exception almost 12 years ago

  • Status changed from Needs Work to Done
  • Target version set to N/A
  • Request Type set to Feature Request
  • Affected Program set to None
  • Affected Users set to Developers

Standing tasks will no longer be handled as ticket.

Actions #11

Updated by admin almost 12 years ago

  • Status changed from Done to Closed

Automatically closed after 30 days

Actions

Also available in: Atom PDF