#apertus IRC Channel Logs

off to bed now ...

sry - lost the page

there you are :D

telegram, discord, irc, hangouts, messenger :)

see pm

se6astian, just to be clear, it was the stuff from your links about open-source projects and handling them

ypu

yup

we should discuss the general response and request structures

it would help to define json conversions

google doc?

yes

such stuff as whoami or login or something else, would be placed in a module called "general"

so we know where to look for overall configs and infos

because i want to configure the front-end interface based upon the module availability

not implemented yet, but like we discussed in last meeting, a JSON file with settings, an example is already in your gist at the top

so whoami => daemon

"whoami" would be placed in the command attribute for module "general", other values wouldn't be handled by related method

sorry, not commands, but attributes

right - but the flow would be client(whoami) => daemon(URU) => client.URU(modules?) => server(modules) => client(CMD)

i don't care

if you have some alternative to json, then you're welcome

but i suppose in the interest of time json exists and works

json is just the format to WSServer which translates it to flatbuffers packages to daemon

https://google.github.io/flatbuffers/flatbuffers_guide_tutorial.html

we discussed it already and flatbuffers from client is cumbersome and should be handled by WSServer

then we stick with json

right

do you have a current WSServer in git somewhere?

https://github.com/apertus-open-source-cinema/beta-software/tree/dev/software/control_daemon/API_WS

all the best

ok - thanks for getting us together

so we need to define the messages

e.g. sender, module, command, value, timestamp, status

maybe also value type for conversion, if it is string or int

https://www.w3schools.com/js/js_json_datatypes.asp

aperture could be int, but owner a string

that is how i guarantee that the type is what i need in js

ok

front end will be responsible for text messages, server will just sent some text markers, e.g. "STATUS_PERMITED", "STATUS_DENIED"

those are things that are spec'd in the messages type (line 58)

yes, seen them, that's why i'm trying to get them straight, without whitespaces (and maybe capital letters), seen a lot of problems at work, when people started to send texts from backend and wondering why translations are not working

do you want to fork the gist

ok, great!

but that's the problem at the moment, can't wrap my hand around required stuff

which part?

required?

is UUID sufficient or do we need some package index counter etc.

so that the two can "lock to each other"

and i am not sure what you mean with package index counter, but at the top of the gist is the "module registration"

i would need that stuff to know how to construct the interface

"to daemon" is abit wrong, should be "to wsserver", will change in a moment

maybe we should always send a whoami packet and then a command packet

or we include the whoami struct in the command always, like the way you did

js handles everything like a text, not really, but it appears like that

what about the access attrivute, how could it be included in the package?

you know, that is really an implied attribute

on the first handshake its important

because the webinterface should always have access once locked to the WServer

or something like that

that sounds logical

is it giving a status of some module?

every module will receive some pre-defined set of methods, like current state, last error etc.

yup

assume the webclient makes a bunch of changes to the initial state of the camera

and on reboot and reconnection, the client *could* send the last known settings to the camera

wsserver would send some sort of ACK, probably in status, then you would check against local storage

i will extend my gist fork or maybe also the task with usage cases in the lab, so we can inspect them for possible problems or shortcomings

https://lab.apertus.org/T762

just saw it - thanks

implementation will be adjusted today, as it's not that much, most things are already there

have ditched REST server (pistache lib) and replaced by uWebSockets, it still uses nlohmann json lib for processing

great

https://github.com/uNetworking/uWebSockets

this allows me to test stuff independently, there is also a flag, which prevents memory mapping, when not using ARM environment, like the camera, and so tests do not crash on normal PC

they are simple and sufficient for now

if we need more complicated setup with routing etc, then i would consider libwebsockets again

in order to test the front end

yeah - i know.

travis ci is still passing, so it should be not a big problem to build it, otherwise just cotnact me

hard to implement something without a possibility to see the result and if it works correctly

is the build process here still current:

yes, but let me get another doc

at the bottom is the flag, which should prevent crashes on normal PC

ok cool.

i was just about to ask

we could serve the page from apertus.org

and then ask the user to enter the IP address of the camera

and what about filming in the nature, beyond any wifi and mobile network?

which means that the smartphone has it cached on the device

of course that is bad if you have to use another device for whatever reason

maybe the best is still to serve directly from the camera

remember that, but for which part?

and then we pass messages across ws on some port 7070

but netcat might even be already available

https://lab.apertus.org/T937

it is a super small binary

is it waking up or running permanently?

https://stackoverflow.com/questions/16640054/minimal-web-server-using-netcat

so you want it for first handshake?

well, it would exist up to the first handshake

because the front end has all of the chrome it needs to run for the lifetime of the session

no one

ok, sounds interesting

there is no need ever to hit the server again for anything once the html,js and css have been delivered

that has been my strategy since day one

if you like, i will make a POC netcat command with assets to build the client interface

we need to incorporate the vue build into beta-software at some point

asked se6astian about some splits for repo some days ago, as it grows and the build takes about 40 minutes to finish, it makes things harder to tests in parts

at least it's the time on travis ci

yeah, maybe faster on a private gitlab-ce

as long as i maintain full adminstrative rights

i think that is a good idea

but first we need the proof of concept done

and actually use that to build the release

also because then different developer teams can really own their part of the "product"

yup

owning is a bit hard in open-source

https://lab.apertus.org/T824

i would smile about it usually, but i know all too well that from my work, that there are not many people who want to be merge monkies

hehe

jeez

yeah

sure

in the sense of WS

nothingismagick: are you still typing?

missed a question mark ;)

like i said, the client needs to know which modules it can control in order to construct the interface

module: "general", command: "get-available-modules"

module: "image-sensor", command: "get-available-commands"

i would prefer underscores

image_sensor

let's stick to small letters for now, if we need conversion, then it will be added when demand arises

toLowerCase or so

so the client and server handshake

client iterated over modules and gets available commands

ok

it seems like a lot of round trips

we can pack multiple commands in 1 package

you could do the "all modules" request and would get a list of modules pluss all the commands for each one, nested of course

that is exactly how the scaffolding of the interface works

maybe a value can be an array

[60,100,200,400,1200,2400]

that's the idea, but server and client have to know that it is an array

well, i guess the client would only ever send one command block, no?

available modules | module -> [command 1, command2| ....

but the first response is JSON all the way down

but let me check it first and then we can discuss it again, need practical triage for that

but you can have an object within an array

i know, it is more in the direction of c++ and the json lib, but i will add another struct with command description, with possible values and such

will now start with adjustments for message handler

yep, something like that

this is exactly how i create the "store" of the data in the front end

by the way, i can also create android and iOS apps via Cordova and Mac,Linux,Win via Electron with the exact same code base.

possible to make a testflight version for beta testers (up to 100 installs i believe)

i imagine the low-hanging fruit here would be to make an electron app

of course

an electron app gives much lower level access to the host than a website in a browser

if we have something for hands-on, then we will surely get response and requests from people, to analyze the needs

i have to go to make dinner - anything else please on lab or email

hey

Any new team talks planned? Last release has been almost 6 months ;)

plenty of TT in the works

*hfr for highframerate

Can imagine.. i know its a "far down the road" goal ;)

I just can work with it ;)

Not not really.. but i would have to struggle hard to follow your code - and most of my time goes into content creation..

Anyway.. dinnertime. Thx n bye!!

Yeah. Mostly sports.m

Thx. Good luck! You doing a great job!!

off for now ... bbl

hi TofuLynx, how is it going?

I am going now to my PC and I will attempt to finish the borders demosaicing. what do you think about having 4 for loops, one for each side?

see no advantage there

How would you suggest to do then? How do i make a function that goes in the row, they along the column, again in the row and back to column?

with a flag?

flag?

and vice-versa

Hmm, I will try the two for loops, one for rows and one for columns, I think its simpler

Okk!

it's 10pm for you, here it is 11pm then

have to get at 6am for work, so trying to get to bed not that late

yeah, makes sense!

i know, have 3 gsoc trello boards open and looking from time to time at them

Do you have any remarks or suggestions for me so far?

will visit vienna soon, and of course apertus, maybe i can try to run some tests, if a camera is there

How usually do you visit apertus?

xD

Anxious for it?

Hopeful it will be cool!

will try to look through them and print out some cool ones

daemon should be a central place to control the modules of the camera, like image sensor or read out temperature

not a fan of selfies

will you be taking pictures with an axiom, or with your equipment?

Oh Cool :P

I wish I had a professional camera

also less weight and more stability

nope, just general plans

had not much time lately, because of moving and work, to shoot many photos, so new camera would be pointless, trying to get most of my equipment

so, off for today, as always, if questions arise, you know how to contact me through here or other stuff

good night

nn