Deploying DeadLetter Learn DeadCL DeadCL Tutorials Trusted Domains Publishers

Walk throughs

Author Keys Conversations Libraries Arrays

Network Status Community Hub Contact Us



DeadLetter Arrays

Walk-through



An Array, is an abstract fluid data repository used with RI to organise, interpret and store object information when specified within a DeadLetter Conversation.

Arrays are typically used to add data driven intelligence, speed & accuracy to Conversations performing repetitive task, such as image recognition, cataloguing and object monitoring.

The Basics

Arrays are used to provide interpretable data resources external to local & remote libraries, primarily to offer variation on defined objects. Our first step is to organise our array and connect it to an Author Key.

Arrays need to be easily accessible and should be linked to the original author. To achieve this just include your Author Key;

*dld.keyset('AUTHOR-KEY-deadID')

Include a call statement for the object you're interpreting;

CALL - [SUBJECT_OF_ARRAY]
This is where the the subject can be referenced (if you're using our Object Management Library to manage your array this value should be; OB.D0.





*dld.keyset('AUTHOR-KEY-deadID') *// COPYRIGHT 2018 YOUR NAME //*
CALL - [SUBJECT_OF_ARRAY]

Attribute definition

Arrays require five fixed attributes they are;

'_NAME' This provides the name structure
'_USER' Defines the user (for each) class within the Array
'_AUTHORITY' Sets the importance of each class, this value can be fluid or fixed
'_REQUEST' Catalogues object requests for each class, this value can be fluid or fixed
'_POST' Defines how the Array is to interact with your Author Key and Conversations

This example transfers Array management to the root objects defined in our Object Management Library. This provides a higher degree of protection and better control over your Array.



_NAME [ //RECALL OB.D0 ]
_USER [ //RECALL OB.D1 ]
_AUTHORITY [ //RECALL OB.D2 ]
_REQUEST [ //RECALL OB.D3 ]
_POST [ //RECALL OB.D4 ]

Initialising

Along with our root attributes an Array requires initialisation. This process simply aids RI  in correctly executing your request.

This sets the initial value of OB.D5 (detected object five, withinObject Management Library with a value of zero, while the sub-class loads its value from '_AUTHORITY'.

This process will need to be repeated for each class input.


        
  
 RECORD_ [
  # // OB.D5 -- _VAL 00.000
	
	{
		OB.D5-1 OB -- WING_STATE
			_VAL *00.0*
	}
	
  ]
   

Brokering

Is accomplished using a separate file in which you'll need to define your Arrays fixed attributes. It's vital that once set you do not seek to update any attribute, without first backing up the Array.

In this example the objects being stored are defined within the file LIBRARY_NAME;

[ //CALL LIBRARY_NAME -- BND /RW CLASS #0.00 ]

We've locked other Authors from contributing with a root fuse command;

[ ^FUSE ?DLD.KEYSET_ ]

Next we've created three classes and manually set four sub-classes;

[ //SET OB.D5 -- 00.000
//SET OB.D5_1 -- 00.500
//SET WING_STATE OB.D5_* -- 00.300 ]


[ //SET OB.D6 -- 00.050
//SET WING_STATE OB.D6_* -- 00.500 ]


[ //SET OB.D7 -- 00.050
//SET WING_STATE OB.D7_* -- 00.500 ]


Followed by setting all requests to be maintained within the Array;

[ //CALL A: *$ ]

Finally we set the Author whom the Array publishes to;

[ //POST DLD.KEYSET-DO-ID: ]



_NAME [ //CALL LIBRARY_NAME -- BND /RW CLASS #0.00 ]
_USER [ ^FUSE ?DLD.KEYSET_ ]
_AUTHORITY [ //SET OB.D5 -- 00.000 //SET OB.D5_1 -- 00.500 //SET WING_STATE OB.D5_* -- 00.300 ] [ //SET OB.D6 -- 00.050 //SET WING_STATE OB.D6_* -- 00.500 ] [ //SET OB.D7 -- 00.050 //SET WING_STATE OB.D7_* -- 00.500 ]
_REQUEST [ //CALL A: *$ ]
_POST [ //POST DLD.KEYSET-DO-ID: ]



Trusting your Array

For your Array to function, the Author specified as the owner (listed using dld.keyset) must include an import statement in their Author Key.

This should be included directly beneath domain.com = DOMAIN within the Author Key.



@import a: [LIBRARY_NAME]