• Content Count

  • Joined

  • Last visited

Everything posted by Etienne JULLIEN

  1. After carefully reading all the posts, I'm inclined to agree with Yaron. LMS obviously already have "intuitive" knowledge of the "repeatable" characteristic of a record. And they already have rules to handle records depending on this characteristic (Replace "GAX" or Add "ENGMARK" for example). So it makes sense to keep it simple and use the same ruleset for PROC records. Maybe the only thing we need, really, is for this repeatable characteristic to be explicit in the DCS records definitions.
  2. Good morning Robert, The option we were considering before you made clear that PROC records were to be additive in case of "repeating records" was that they would totally replace default values. Hence, to send an additional ENGMARK to a specific device, you would need to declare again all the default ones: DO=B ADD=1.75;2.50 ENGMARK=MASK;MainDesign;.... ENGMARK=TXT;A;.... ENGMARK=TXT;B;.... ENGMARK=DCS;ADD;.... PROCBLK=1;ENG;VEN1;... 1!ENGMARK=MASK;MainDesign;.... 1!ENGMARK=TXT;A;.... 1!ENGMARK=TXT;B;.... 1!ENGMARK=DCS;ADD;.... 1!ENGMARK=MASK;ExtraVen1... But since it forces to duplicate all the default engravings for each device that requires an additional/different one, it did not sound like an optimal solution. Now, I can see 3 choices for repeating records: We stick with the "Replace" global behavior (as soon as you have a hit for a record on a given context - DEV+VEN+MODEL+S/N, or DEV+VEN+MODEL, etc. - , you take all entries of this record on that context, and ignore the other context levels) We can let the LDS give specific instructions (delete, replace, add) We can have a "by definition" behavior such as the one you are suggesting First option is pretty simple, both for LMS and LDS, drawbacks being records duplication. Second option would require us to define a much more complex syntax than the current PROC. Third option would require to explicitely tag all "repeating records" as such in the DCS, and have the LMS aware of that particular characteristic (so that they can process the PROC record accordingly). Option one strikes me as the easiest way to go, but it sure is more brutal and less graceful than the third one.
  3. Sorry to reply to myself, but the editing policies are quite strict around... This does not sound as clear as intended upon reading with fresh eyes, so please replace it with
  4. Greetings Yaron, Once again, thank you for your acute awareness and relevant concerns. My first reaction to your initial post was the same as Paul's, as it seems to be the only way to address the problems you mention with the current definition. As you stated in point #3, this is probably a discussion we should have had as soon as the PROC record was introduced, since it requires distinct behavior depeding on the record type (singleton / collection) and the LDS instructions (replace block / add / replace specific entry). One idea could be to use a different separator (such as '+') when we want the LMS to "add". But I feel this would require a lot of thinking to make sure it covers all cases. Since we have a non-optimal workaround with the current definition (LDS needs to re-specify all collection entries in each block), I would suggest that we let this one out in 3.12, and try to draft a more optimal solution here, to be validated during the next VE, if that's ok with you.
  5. Greetings, Sorry about this easter delay. Here is a revised proposition for the PROCBLK record. VEE 2018 - Proposal of DCS records evolution - Essilor 20180401 -V5.pdf
  6. Hi Paul, Sure thing, I'll draft an updated proposition by the end of the week.
  7. Greetings, I concur 100% with those propositions. The best fit should be found each time (DEV+VEN+MODEL+S/N > DEV+VEN+MODEL > DEV+VEN > DEV > master LMS) for each record. If you do not want the parent value to be inherited, you just explicitely respecify its value in the child block, as in Paul's example. Thank you!
  8. I can remember of 2 benefits having the prefix: - It makes it easier to scroll down a DCS packet and visually differentiate the blocks (as opposed to being very cautious and try not to miss a PROCBLK record when several blocks are following one another). - It might ease the LDS 2 LMS support to have a block identifier (as opposed to finding it by looking the the specific device / vendor / model / SN). But honestly, as long as we can agree on a solution that allows us to have device-specific dataset records , I'll be 100% happy.
  9. Greetings Yaron, and again, thank you for your time! Interesting comments. Ok for the PROCBLK, I keep your suggestion in mind, let's discuss this during the DCS meeting next week. Regarding the SDFMODE, if I understand correctly what you are saying, you'd rather see this record completely removed and replaced with a full URI in LDPATH. The suggestion here was trying to stick to the original design (SDFMODE telling which protocol to use, LDPATH hosting the surface identifier). But this seems to be a valid option, and I propose that we discuss it next week, too.
  10. Many thanks for the extensive and relevant comments, Yaron. Regarding PROCBLK, as you pointed out, this is a LDS=>LMS record, exactly as the PROC one. It is never supposed to make it to the actual device. I understand your point, though, but I'm pretty sure the issue you are raising with older system letting those labels flow up to the device should be handled during deployment and configuration phase. Basically the LDS should be configured not to use such records in that specific case. The idea you suggest (inserting a fake label in each line within a proc block) could work as a safeguard, too, but I'm not sure it would be as easy to manage by LMS as the current proposition. We can discuss this with LMS teams, of course. Still, the absolute target is that devices should never get such records. Regarding the SDFMODE, the point is that depending on the mode used, the identifier sent in LDPATH tag might not always be a filename. And might not be inserted directly in the SDFMODE record content, or not always in the end (for http requests, for example). Basically, the idea is to have SDFMODE contain static data, and the variable part in LDPATH. In some protocols, such as ftp or http, the device might also have to add credential informations (login/password, etc.) that we don't want to specify in the LDS data obviously. So the SDFMODE value will be completed / altered anyway in those cases, which is why it does not sound too bad to have the LDPATH contain the variable part (file identifier / name). Basically, the final URL / Path to access the surface would be composed The SDFMODE static part THE LDPATH variable part Possibly another static configured part (depends on the SDFMODE + LDVEN)
  11. Good morning Paul, Here's one for starters: Thank you! Etienne.
  12. Greetings, Here is a formal proposition for the new PROCBLK record we discussed during last VEE, as well as a proposition to extend the SDFMODE to more protocols. Basically, PROCBLK works the same as PROC, but enables declaring whole blocks of device-specific data. Thus, dataset records such as TRCFMT could be included in such blocks. The SDFMODE modification is just an extension of the syntax allowing more protocols (if we don't do this, we have to make modifications for each new protocol, such as https, for example, which is not allowed in the current state). See you soon! Regards, Etienne. VEE 2018 - Proposal of DCS records evolution - Essilor 20180201.pdf