[Bitrepository-devel] Tilføjelse af 'Recipient' element til den generalle Message type i protokollen

[Mikis Seth Sørensen]

Jeg tror 'to' feltet primært er med så man direkte på et meddelses objekt kan angive hvordan det skal sendes uden at skulle have dette liggende som data ved siden af, det er meget rart.
Enig at den nuværende navngivning ikke er optimal, jeg er hver gang jeg kigger på disse elementer nødt til at se i xsd dokumentation hvad der forgår.

Hvis vi skal til at rette i dette kommer det til at ødelægge en hel del.

Mit forslag til en evt. renavngining er at vi skifter som følger:
Destinations ifølge ActiveMQ property syntaks:
To -> Destination
ReplyTo: Uændret.
Components
Recipient -> To
From: uændret.

Dvs. vi ændrer semantikken for et element og derfor endelig får brug for at bruge vores protokol minVersion som så skal sættes til 24 :-)

Who dares wins???
Mikis

From: Asser Schrøder Femø <assf at kb.dk<mailto:assf at kb.dk>>
Reply-To: List for the Bitrepositorys developers <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Date: fredag den 1. februar 2013 14.07
To: List for the Bitrepositorys developers <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Subject: Re: [Bitrepository-devel] Tilføjelse af 'Recipent' element til den generalle Message type i protokollen

Det lyder fornuftigt nok.

Nu var jeg jo ikke med dengang protokollen blev lavet, men To-feltet virker umiddelbart lidt redundant? Hvis man lytter på et topic må man vel antage at man som udgangspunkt er interesseret i alle beskeder sendt dertil.

Jeg kan se at kb-pillar kun bruger To-feltet når der sendes et svar baseret på en forespørgsel (her bliver To kopieret til ReplyTo, men det er vel lige så godt at sætte ReplyTo til enten pillarens "private" topic eller det i collectionsettings definerede broadcast-topic, afhængig af beskeden?).
Bruger I To-feltet til noget?

Og så er navngivningen lidt inkonsistent synes jeg; To er et topic, men From er et komponent-id. Her ville jeg forvente at To og From var den samme type. Det er nok alligevel lidt sent at diskutere, synes bare det bliver mere rodet når der så kommer et Recipient felt oveni som er komponent-id ;-)



________________________________
From: bitrepository-devel-bounces at ml.sbforge.org<mailto:bitrepository-devel-bounces at ml.sbforge.org> [bitrepository-devel-bounces at ml.sbforge.org<mailto:bitrepository-devel-bounces at ml.sbforge.org>] on behalf of Mikis Seth Sørensen [mss at statsbiblioteket.dk<mailto:mss at statsbiblioteket.dk>]
Sent: Friday, February 01, 2013 1:11 PM
To: List for the Bitrepositorys developers
Subject: [Bitrepository-devel] Tilføjelse af 'Recipent' element til den generalle Message type i protokollen

For at kunne understøtte muligheden for at angive en specific komponent som modtager af meddelser ville jeg gerne tilføje et 'Recipent' element til Message typen. Det vil også betyde at To/From semantikken på meddelser bliver mere symmetrisk. Den nuværende Message type indeholder:

      <xs:element ref="bre:To">
        <xs:annotation><xs:documentation xml:lang="en">
        Identifies the destination which the message is sent to.
        </xs:documentation></xs:annotation>
      </xs:element>

      <xs:element ref="bre:ReplyTo">
        <xs:annotation><xs:documentation xml:lang="en">
        Identifies the destination any responds should be sent to.
        (blank if not relevant, e.g. for alarms)
        </xs:documentation></xs:annotation>
      </xs:element>

      <xs:element ref="bre:From" >
        <xs:annotation><xs:documentation xml:lang="en">
          The ID of the component responsible for this message.
          (blank if not relevant, e.g. for alarms)
        </xs:documentation></xs:annotation>
      </xs:element>

Det nye 'Recipent' vil blive optional og skal kun bruges hvis afsenderen sender meddelse til en specifik modtager. Dette er motiveret af BITMAG-827<https://sbforge.org/jira/browse/BITMAG-827> Include receiver component ID id identifyrequest message header properties<https://sbforge.org/jira/browse/BITMAG-827>

Så vil jeg også tage BITMAG-787<https://sbforge.org/jira/browse/BITMAG-787> The getFileIDs model in the protocol should be trimmed<https://sbforge.org/jira/browse/BITMAG-787> med i denne protocol opdatering.

Nogen protester??

Mvh
Mikis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20130201/dd28c49a/attachment-0001.html>