[TF-AP/Thing API] ThingFilter server attribute

[ClaesNilsson]

dictionary ThingFilter {
    attribute DOMString? type;
    attribute ThingProximity? proximity;
    attribute DOMString? id;
    attribute DOMString? server; 
};

So this is the address, URL, of a server containing a directory of "things", e.g. an IETF CoRE Resource Directory?

[louaybassbouss]

@ClaesNilsson after Nice F2F Meeting, we need to refine this more. We agreed that the filter parameters are different for various discovery technologies. I see these options on how we can proceed on this:

• A new Filter class for each discovery Technology. This class may extend an abstract ThingFilter where we define generic parameters. Example: BleThingFilter, UPnPThingFilter, MdnsThingFilter, etc. and each of them defines its own filter parameters. The ThingRequest will still accept any subclass of the ThingFilter as Input.
• A generic ThingFilter with vocabulary for each Discovery Technology. For example:

filter =  {
   "ble": {
       "proximity":  ...
   } ,
  "sparql": {
        "query": ...
  }
};

What do you think?

[h0ru5]

I'm in favor of the first.

Considering an ThingFilter with two arguments such as type (here meaning the type of filter) and a config object (Map) would give us a simple interface and yet support also complex cases.

example:

let filter =  { "query" : "...", "endpoint" : "..." };

ThingRequest("sparql",filter).start().then( (things) => console.dir(things) );

let otherfilter = { "foo" : bar"" };

ThingRequest("somethingelse",otherfilter).start().then( (things) => console.dir(things) );

[egekorkan]

Continuing at w3c/wot-scripting-api#226 . Closing