Talk:Spec:Packet

Contents

[edit]

Inheritance family matching 

? - This modifier asks the recipient for the contents of any persistent variable matching the inheritance family provided

Could you provide an example for such a inheritance family matching? --Marenz 11:20, 11 April 2010 (CEST)

<lynX> It could be psycmatch or just abbrev but we need to decide how a state resync would actually look like and if it has anything to do with a ? glyph. Until then let's better forget about this glyph.

[edit]

ABNF

Current 0.9 PSYC syntax also provides for multi-line continuation and list continuation which are missing here. Both continuation techniques are obsoleted by length-prefixed variables - the rest of the syntax may stay until 1.0.

<lynX> hmmm... people.. what we are doing here is 1.0. at least concerning the syntax.
<Elmex> I think thats okay. At least we have now multiple parsers already for C, C++, Perl and LPC. (see psycpp :-)
I would opt for making the spec for the PSYC 'we all want to have'. So that after the specification is mostly finished we can start implementing it and discuss the shortcomings of it. On the side: How are you planning to do length-prefixed variables? The problem, if you just make parts of a packet "opaque", will be that you can't frame psyc-packets anymore and need a stream-parser, which can be much harder to implement. Currently all you need to do is to search for "\n.\n" and take what you got and stuff it into the packet parser. Of course I don't know what you have in mind w.r.t. 'length-prefixed variables', but I guess you will also need to length-prefix the whole packet too. Elmex 02:08, 14 January 2008 (CET)

We already have binary body data and we are discussing binary variables so we can (a) send anything in variables (b) don't have to implement complicated syntaxes just because a variable likes to contain a newline. Framing (from PSYC vars 'til end of body) is only given when a complete outer _length in MMP is provided, which encompasses all binary variables, too. This all means we do indeed need a stream parser for the MMP part of the packet, but the parser will need to know whom to give the packet, anyway, no?

_binary is the module negotiation name for length-prefixed variables (no matter if they actually contain binary data or just a couple of newlines or nothing unfriendly at all). See the Spec:Packet how _length four outer framing is specified now. We also have a third level being the _list type with embedded lengths and you can define your own arbitrary data types in a similar vein.

[edit]

Variables

Here is a part from your draft ( http://www.psyc.eu/modifiers.html ) that I (Elmex) need some clarifications for:

[edit]

Treatment

Receiption of variable information SHOULD be passed to the target object of the message by doing method calls on it. The technique used to translate the combination of glyph and variable into a method name works like this:

What is an object? How do I find "the target object"? Elmex 02:22, 14 January 2008 (CET)

Warning: Most implementations do not use methods like this, they simply operate on the variables at parsing time. The final results are the same however. So the spec needs an update here. TODO

As described on Parse this seems to be indeed the usual treatment. Should this maybe simplified to the original definition I had in the spec? Elmex 02:22, 14 January 2008 (CET) 
   "=" triggers a method "_assign_{variable}"
   "+" triggers a method "_augment_{variable}"
   "-" triggers a method "_diminish_{variable}"
   ":" triggers a method "_set_{variable}"
   "?" triggers a method "_query_{variable}"

... That's a suggestion for a standardized way to map var modifications to PSYC method events. De facto we have never implemented this. Vars are modified inside the parser and only passed to the applications when a method is provided. I still don't know which approach is best - in most situations the thing above is humbug, but what if you receive modifications to the _members list of a place without visible messages. The events are still real, you simply aren't supposed to show the messages, and the traffic is reduced. Right now we don't do this in any case - if a place doesn't like to show who's joining or leaving, it doesn't send anything. It's nice to have this thing here saved in the Talk: page of the Spec, but we don't need to work with this any further methinks. --lynX

I think we need to work this out, because a part of Spec:Packet was commented out by you, saying: ... this definition of glyphs is incorrect *and* nerdy (hard to understand using cvar cvars pvar and pvars as tech terms which is all insider jargon). Use the definition from the drafts!. We need to describe how to interpret the glyphs, and above I quoted the definition from the drafts! Or do I miss what you meant by draft? Did you only mean that pvars and cvars are bad terms? What alternative do you suggest to call them? --Elmex

<lynX> Alright, so the definition in the drafts sucks. Sorry, I didn't look at it in a while. We need a spec that explains how to apply the glyphs to variables. For 0.9 we don't even need to define how + and - operate on lists, because we don't use it anywhere. So the definition is rather simple, ":" defines a current variable only, "=" sets a persistent var (which also counts for the current var unless it is being overwritten differently soon after). :_variable without data is necessary to temporarily delete a pvar. =_variable without data deletes a persistent var. I think muve also allows for "-" to remove a persistent var (in its syntax without data), but '+', '-' and '?' are not really being used in PSYC 0.9 and should therefore only be reserved for future use like any other glyph, too. The terms pvar and cvar should not be used in the spec, they are jargon abbreviations for current variable and persistent variable which are more civil to read. It makes sense to introduce the + - operators with a future PSYC that actually supports distributed state.

See also Talk:List for new ideas on lists and tables.

[edit]

Keyword Naming

TODO: work the content of that draft (keyword naming) into this Spec:Keyword.

I guess this is going to be discussed above in the question about 0.9 vs. 1.0, but: Which part is mandatory? Did you mean only the basic things from http://www.psyc.eu/keyword-naming.html? Elmex 02:26, 14 January 2008 (CET)

Yes, those are the basics. All the other stuff on the wiki page isn't wrong - but we can look into that step by step. --lynX

[edit]

Inheritance

Inheritance for variables is necessary and will be implemented more than just in a couple of spread out abbrevs and psycmatches.

[edit]

Opaque Variables 

   lynx: der sinn der sache ist ja auch late parsing
   lynx: du siehst <var> <len> <data> und saugst data einfach gemäß längenangabe auf
   lynx: die eingebetteten längen einer liste ignorierst du bis du sie brauchst
   elmex: sehen dann alles variablen so aus? 
   elmex: s/alles/alle/
   lynx: naja, listen sind ja ne ausnahme
   elmex: also nur _list variablen?
   lynx: und nein, die meisten vars sind frei von newlines, also können sie ohne·
         länge dastehen
   lynx: jede var die verbotene chars enthält wie newline 
   lynx: muss length-prefixed sein
   lynx: so ist der neue syntaxplan
   elmex: also <var> ( <len> <data> | tab argument nl | nl ) ?
   lynx: bisher hatten wir für newline ne sondersnytax
   lynx: nein, data und argument ist dasselbe
   elmex: also <var> ( [<len>] tab argument nl | nl ) ?
   lynx: <var> [<len>] TAB <argument>
   lynx: ja so in der art 
   elmex: zwischen <var> und len kommt dann aber ein space?· 
   lynx: noch nicht entschieden, aber wahrscheinlich
   elmex: <var> ([<space> <len>] tab argument nl | nl)
   elmex: ok

See also at the end of Talk:List.

Vorschlag BNF: 

modifier = glyph variable arg
arg      = 1*(tab argument-part nl)
         =/ space 1*(length tab data) nl  ; data is <length> bytes long
         =/ space list nl
         =/ nl
list     = list-value [ "|" list ]
list-value = ; byte-string without | and newline
space    = %x20
length   = 1*(digit) ; digit is an ASCII digit

... Die Listensyntax gilt aber nur bei _list-Variablen ... normale Variablen haben einfach irgendein "arg" ...

<Elmex> ich habs nu in die spec bnf eingebaut, inkl. dem _list requirement

<lynX> dann kann dieser block ja hier weg.. zing!

[edit]

new bnf questions

[edit]

length

I would propose 

 0 < length < somelength

Restricting somelength to 2^32 - 1 will still yield variables 4 gig in size. We still have body for fragmented transfer of data larger than this. This would impose a maximum size of length in the BNF, too. Is it allowed to have a length of 

 000001

or should the BNF forbid that? fippo thinks that enforcing this requirement is too difficult. Just accept it.

<lynX> Why does a grammar need to suggest any hard limits? This sounds so 640K to me.

[edit]

Modifiers

<Elmex> Ich wollte mal wissen: Worauf beziehen sich die modifier in den packets eigentlich? Besonders im falle von PSYC modifiern: Beziehen sich die modifier auf den state der source entity? Und wenn ja, was is die source entity? Is der in _source? Ist es die logical source die in Spec:Glossary beschrieben ist? Und um da nochmal zurueck zu kommen auf die variablen typen: Wenn ich einen state fuer den anderen entity manage, dann MUESSEN die typen global feststehen, weil ich doch sonst garnicht mit den modifiern umgehen kann oder mit den daten in der variablen.

[edit]

Packet ID

<lynX> packet IDs are work-in-progress for future PSYC versions.

Sometimes you want to refer to a packet (eg. in the _relay variable, see also routing.txt). Then you compute the packet id as follows: 

  packet-id = concat (source, logical taget, counter, [fragment])

(For a definition of logical target see routing.txt.)

TODO: how is source defined?

[edit]

Checksums

<Elmex> kuchen suggested that checksums would be useful for UDP transmission. I suggested him to use _hash_content_SHA1 (or whatever other algorithm is used) for now. Does that makes sense lynx?

<lynX> psyced's net/psyc/parse.i currently supports packet checksums using a _check_SHA256 or similar variable with other cipher name. See the wiki page for spec.
<Elmex> OK, this means no simple hashes. Sorry kuchen, as we want an eierlegende wollmilchsau mit eingebautem handy.
<lynX> Okay now I understood what the intention was. psyced now supports reception of _check_integrity_SHA1, but doesn't generate that. I'll document it on checksum, too.
<Elmex> Thats great, I will put it into the spec then when the time comes
<fippo>: crc32? why sha?
[edit]

=/ syntax

<lynX 13:26, 30 May 2010 (CEST)> I don't understand this one line in the list syntax paragraph that has a =/ instead of a =, and why elmex had it with a 1 *(...) while Marenz now changed it to list_value *(...). I guess I would have to reread the ABNF specs to make sure that part is correct. Sigh.

<Marenz 13:52, 30 May 2010 (CEST)> I changed it because I wanted consistency. I don't care if it is 1*(..) or val *(...) as long as it is consistent. about the =/ .. I guess a just / would be more consisten here, too. Because it is that way in the Packet ABNF.
Retrieved from "http://about.psyc.eu/Talk:Spec:Packet"