getContainerDataURL

[andries]

als je multimedia wil streamen via CWP moet je de function getContainerDataURL gebruiken. Ik heb echter het gevoel dat die steeds het intern IP adres teruggeeft, en niet het extern... Voor afbeeldingen etc werkt het wel zoals het moet.

 

is er iets dat ik heb misgelezen, of is dit een bug?

[Bruno VDK]

getContainerDataURL : Returns the fully qualified URL for the specified container field.

 

Dat is het path van het container veld, zodat je met oa GetField() kunt werken.

Gelinkt aan de toepassing zou dat inderdaad het intern IP adres moeten zijn.

 

Wat als je eerst een variable met getContainerData declareert: URL to container field contents

 

Die variable gaat dan in getContainerDataURL: URL of the container field contents to get

[andries]

getContainerDataURL zou de streaming url moeten teruggeven, maar als het intern is werkt het niet op een publieke website. Of moet ik dan die streaming gaan routen? (lijkt me beetje overbodig)

 

Ik benader de website wel via het externe ip adres, want de webserver voor de website en de webserver voor de CWP staan niet op dezelfde machine, nog zelfde locatie...

 

ik heb dus

$fm = new FileMaker ( "filename" ; "extern ip adres" ; "username" ; "password" ),

en dan gebruik ik gewoon

 

$url = $fm -> getContainerDataURL ( $path );

 

en hier krijg ik dus niet het extern IP adres terug voor MP3, MP4 en PDFs, maar het intern.

 

Voor afbeeldingen krijg ik wel het goede IP adres terug, maar hier zit natuurlijk streaming niet mee in het verhaal.

 

 

$path heb ik inderdaad verkregen door

$path = $record -> getField ( "myContainerField" )

[Bruno VDK]

Wat als je "filename" vervangt door NULL.

 

Het gaat dan default http://localhost weergeven.....

 

Zelf heb ik nog nooit streaming gedaan...

Het routen was echter ook mijn eerste idee...om het aan het werk te krijgen.

 

Ondanks het feit dat dit inderdaad een beetje overbodig of omslachtig lijkt, het zou kunnen werken.

Later zoek ik dan wel een manier om het te vereenvoudigen.

[andries]

mja ik vervang nu gewoon in de php code het intern ip adres met het extern, en dat werkt wel... maar is natuurlijk niet erg handig

[Jeroen Aarts]

Andries, ik heb het net even getest in een gelijkaardige opstelling (1 machine waarop filemaker server draait, 1 machine met een webserver), en ik kan het issue bevestigen.

 

Het is gewoon een bug volgens mij. Voor foto's krijg ik inderdaad mooi het externe ip (of de hostname) terug, maar voor een video krijg ik het interne IP adres à la 'http:///Streaming/....'

 

- Jeroen

[andries]

heb het er met Thomas Kunetz over gehad, en zijn antwoord was: in zo een configuratie, hoe kan de web component het extern IP adres kennen van de database server (die de streaming op zich neemt). Heeft hij wel een punt natuurlijk...

 

Het enige wat ik dan kan zeggen is dat de architectuur van de FileMaker Server niet helemaal klopt en dat de streaming ipv door de Database Server eigenlijk door de web component zou moeten gebeuren.

[Jeroen Aarts]

Mja, maar voor foto's wordt wel het juist IP adres of hostname doorgegeven. Ik begrijp wel dat het onder water het aflevereren van een afbeelding of streaming content (of de pointer naar de URL) anders in elkaar zit, maar de externe webserver communiceert sowieso initieel via de web component (Tomcat module) die op de webserver die draait op machine waarop FileMaker Server is geïnstalleerd, en die is zich bewust van het externe IP adres of hostname zoals gebruikt in het request door de externe webserver, en moet dat toch kunnen teruggeven zou ik zo denken (hehe wat een zin).

 

Anderzijds wéét je natuurlijk op je externe webserver, in je PHP code, ook precies natuurlijk welke extern IP adres of hostname je gebruikt. Misschien zou het gewoon netter zijn dat - net zoals wat je terugkrijft met de getField() method - de hostname weggelaten is, en dat je dus iets krijgt zoals '/fmi/cnt/...' of '/Streaming/...'

[andries]

ja idd...

 

ik snap ook niet waarom het streamen via een andere server hoeft... ik denk dat dit met performantie heeft te maken. Misschien geeft het wel te veel overhead als de webcomponent als relay dient tussen de database server en de lokale client.

[Felix]

.