Kiinnitetty keskustelu

Elisa Viihde API Info



Näytä ensimmäinen kirjoitus
Tämä keskustelu on suljettu, eikä sitä voi kommentoida.

415 kommenttia

Käyttäjätaso 3
jj_laaksonen kirjoitti:

jj_laaksonen kirjoitti:

Miten jonkin yksittäisen tietokoneessa/puhelimessa/tabletissa ajettavan sovelluksen kirjautumistiedot voivat olla jonkin GDPR-sopimuksen alaista tietoa? Käyttäjätietokantahan on kunkin palveluntarjoajan hallinnassa eikä millään sovelluksella pitäisi olla mitään pääsyä koko käyttäjätietokantaan. Tietokoneessa yksittäisen käyttäjän käytössä olevia sovelluksia, jotka tallentavat ko. käyttäjän kirjautumistiedot koneella, on olemassa pilvin pimein, eikä kenelläkään muulla ole tässä asiassa mitään ongelmaa.

Kertokaa nyt selvin sanoin, mikä teidän mielestänne tässä on sovelluskehittäjän ongelma? Kehittäjänäkään te ette saa sovelluksenne kaikkien käyttäjien(ne) tietoja käsiinne.


Voisiko joku teistä arvon koodareista nyt kertoa, mikä tässä hommassa mättää?



Tietokantaan ei oo elisalla edes joka räpeltäjällä asiaa, kyllä siel on tasan varma jarru, et sinne kukaan vahingossa erehtyis pääseen. Turha edes spekuloida. Onhan heillä f securen kans diili.
Käyttäjätaso 5
jj_laaksonen kirjoitti:

Voisiko joku teistä arvon koodareista nyt kertoa, mikä tässä hommassa mättää?



Jos sen GDPR sopimuksen päätavoite tuntuu olevan vastuun ja korvausvelvollisuuden siirtoklausaalien saaminen 3. osapuolten niskaan, niin siinä onnistutaan hyvin.

Esimerkkinä;
- Jos asiakas (te arvoisat katsojat), joku viranomainen, oikeuksien haltia tai joku muu taho vaatii auditointia, on se suoritettava 3. tahojenkin. Omalla kustannuksellaan. Ulkopuolisen suorittamana. Arvatkaapa kustannus?
- Jos jotain sattuu, kehittäjän tulisi huomata se 24h sisällä ja ilmoittaa Elisalle (ehkä onnistuu webbipohjaisessa palvelussa), mikä on aika vaikeaa näin työpöytäsoftaa tekevälle.
- Elisa varaa sopimuksessa oikeuden siirtää kaikki kustannukset ylläolevista suoraan kehittäjälle.

Ja tätä rataa. Palautan API avaimen jos näin julkisesti lausumalla olen rikkonut jotain hyshys pykälää jota en kuudelta sivulliselta lakijargonia huomannut.

Joko hahmottuu miksi tässä pelataan omaa pesää turvalliseksi ja vaaditaan jokaisesta asiasta selvästi ilmaistu kanta elisalta. Jota ei muuten ole tullut tähän mennessä kertaakaan. Mainostettu API ja sen dokumentaatio on oma lukunsa, josta on jo keskusteltu pitkät pätkät tässä ketjussa. Siihen en enää mene sörkkimään.

Varsinaista GDPR;n alaiseksi mahdollisesti putoavaa tietoa tuo API tarjoaa vain ja ainoastaan, jos sovellus pyytää kirjautuneen käyttäjän tietoja. Ja tuolloinkin palautuu testien mukaan vain pitkä numerosarja tilausnumerona ja kirjautumiseen käytetty käyttäjätunnus. Ei muuta.

Eli ollaan pattitilanteessa, kunnes Elisan puolelta on selvät ja kirjalliset, jokaiselle kehittäjälle jaellut ohjeet, mitä dataa tulee käsitellä GDPR:n alaisesti, sekä muutenkin mitä tuolla rajapinnassa saa ja voi tehdä. Sekä tietty se 1. postauksessakin jo suuresti mainostettu parempi dokumentaatio.

Olen itse toiminut yli 20 vuotta ohjelmistotuotannossa, ja ei ole ensimmäinen - ja tuskin viimeinen - kerta, että integraatiota tarjottaessa se on huonosti dokumentoitu tai sen sopimus on kuraa. Tämä kierros vain menee sinne top-3 osastolle. Ja todellakin, kun Elisan rajapintaa käyttävistä tietääkseni kaikki on yksityisiä henkilöitä, jotka tekevät tätä vapaa-ajallaan korvauksetta, niin vasteajat eivät todellakaan ole mitenkään yritysten tasolla. Myös koskien näitä lakiasioita, joista jo mainitsinkin aikaisemmin.

Eli malttia rakkaat jullikat. Kaikkemme tehdään, mutta tuo iso E ei tee hommasta mitenkään helpompaa. Varsinkaan, kun kommunikaatio on ollut lähempänä nollaa ainakin tähän suuntaan. En tiedä miten toiset ovat saaneet vastauksia kysymyksiinsä.

Mutta, jos kiitos on vain pään aukomista ja purnaamista, niin ei se ainakaan motivoi meitä ohjelmoijia viemään asiaa yhtään tehokkaammin eteenpäin...

Eli pieni pyyntö suoraan Elisan suuntaan; kommunikaatio voisi olla kova sana? Varsinkin firmalle, jonka leipälaji sen pitäisi olla?

...just my 5c again...
Käyttäjätaso 1
Koittakaahan rauhoittua. Minulla on ollut jo pari viikkoa kaikki materiaalit, mutten työkiireiden vuoksi ollut vielä ehtinyt niihin tarkemmin perehtyä. GDPR-materiaalin olin kyllä silmäillyt läpi, eikä se ollut nostanut esiin mitään ihmetystä. Olen työssäni joutunut tekemisiin satojen vastaavanlaisten yritysten välisten GDPR-sopimusten kanssa jotka osa ovat olleet pituudeltaan moninkertaisia. Kaikista löytyy kuitenkin samat perusasiat aivan kuten Elisankin GDPR-sitoumuksesta.

Muutama random kommentti:

a) Sopimuksessa ei ole mitään mikä ainakaan minua estäisi tekemästä ja jakamasta tekemääni sovellusta eteenpäin
b) Yritykset tekevät tämän harjoituksen saadakseen rastin ruutuun että noudattavat GDPR:ää, sillä heillä on oikeasti isot uhkasakot mahdollisia, jos lepsuilevat näissä asioissa - heillä kun on todistustaakka ja tämä on yksi tapa todistaa että asiat on tehty "by the book"
c) Jos teet sovelluksen API:a käyttäen, joka ei käytä henkilötietoja - et siis käsittele henkilötietoja
d) JOS API:n läpi sattuisi kulkemaan henkilötietoja, mutta sovelluksessa ei ole riviäkään joka käyttäisi sitä tietoa, on helppo osoittaa
e) Lisäksi mitään allekirjoitettua sopimustahan ei tässä tapauksessa tehdä vaan kehittäjä vain sitoutuu käsittelemään henkilötietoja Elisan ohjeiden mukaisesti
f) Kyllä minuakin harmittaa, miten epäammattimaisesti asia on kaikenkaikkiaan hoidettu, mutta itkeminen palstalla ei muuta sitä mihinkään suuntaan - siinä vaiheessa kun allekirjoittaneen kesäloma alkaa ja pääsen API:n kimppuun, täältä tuskin löytää teknistä apua, kun vähäinenkin tieto on hukkunut kaiken vinkumisen ja vonkumisen sekaan
Käyttäjätaso 3
Ennyt väittäis itkuksi asti, vaan jos et ole varma asiasta, niin älä tee / julkaise tekemääsi. Mutta hyvä kun joku edes tietää noista, koukeroista.
Käyttäjätaso 2
Ottamatta kantaa miten Elisa hoiti tiedotuksen, lapun sisältöön ja apikeyn vuotamiseen lähdekoodien mukana vaihteeksi vähän valoisempiakin kommentteja.

Minun tietääkseni SaunaVisio API joka kopioitiin 'as is' vanhaksi ElisaViihdeAPI:ksi ei koskaan ollut virallisesti dokumentoitu ja julkaistu Saunalahden/Elisan toimesta. Nyt sellainen on joten voimme olettaa sen myös pysyvän hengissä. Jaettu dokkari riittää minulle, olen nähnyt paljon huonompiakin tekeleitä. Jaettu API on myös mandaatti sen käyttämiseen.

Siispä aloitin vanhan oman projektini uudestaan. Minulle ei ole tuottanut tuskaa duplikaatit ElisaViihteen sisällä vaan duplikaatit leffakirjastoni kanssa (satoja laillisia elokuvia Kodin kirjastossa). Joten värkkään skriptiä joka yhdistaa ElisaViihteen, Kodin APIn ja IMDB:n tiedot ja etsii niistä duplikaatit. Periaatteessa mahdollista myös syöttää Ellun elokuvat Kodin tietokantaan, jolloin jatkossa "pitäisköhän katsoa joku xxx:n ohjaama leffa" hoituisi yhdellä ainoalla laitteella. Mutta tuo ei valmistu ennen joulua jos silloinkaan.

Ellun duplikaateilla on muuten sama metadataId joten niiden etsiminen on aiempaa helpompaa. Olisi kiva tietää mistä Ellu on ne numerot kaivaneet, jos ne olisi suoraan jonkun julkisen palvelutarjoajan koodeja niin sille voisi keksiä muutakin käyttöä.

Minusta on hyvä että kaikki tallenteet tulee yhdellä kutsulla. Tauhkaa tulee jotain 6 MB ja mukana on tulevat tallenteet (helppo karsia) mutta myös sellaiset joita et ole itse deletoinut vaan Ellu on 'tuhonnut' puolestasi. Esim. vuodelta 2008. Ne on vähän hankalampi karsia. Vanhan APIn kautta ne pystyi jopa katsomaan, nyt ei enää 🙂

Metadata sen sijaan ei tule yhdellä kutsulla, tai en ainakaan tiedä miten. Jos niitä kysyy loopissa yksitellen niin erroria 429 pukkaa varsin helposti. 300 ms tahallinen viive kutsujen välillä näyttää olevan sopiva mutta kun sen tekee 1500 kertaa niin aikaa palaa. Eli paikallinen cache => GDPR(?)

recordingId näyttää olevan kaikille saman sarjan jaksoille sama, joten API-dokumentin delete-komennossa on varmaan virhe - tekemällä sen mukaisesti menisi kaikki Simpsonit kerralla. Mutta ajattelin siirtää duplikaatit tai muutoin jo katsotut (=joku sarja tulee uusintana mutta IMDB tms tietää että olen sen nähnyt) johonkin kansioon skriptillä ja tuhoan sieltä sitten käsin.

My 5c...
Käyttäjätaso 5
st72 kirjoitti:

Siispä aloitin vanhan oman projektini uudestaan. Minulle ei ole tuottanut tuskaa duplikaatit ElisaViihteen sisällä vaan duplikaatit leffakirjastoni kanssa...



SaunaAPI oli melkein sama kuin EVAPI (v1), tein aikanaan eViihteeseen tuen molemmille ja sama koodi ei toiminut suoraan molemmissa. Muistaakseni JSON rakenne oli vähän eriävä. EVAPI(v1) oli enemmänkin SAPI;sta jalostettu versio.

Ihan hyviä havaintoja, tuo tallenteet yhdessä kasassa on vielä käsiteltävissä, mutta tuo mainitsemasi "kaikki vanha sotkukin" osuus saisi olla pois. Vaatii omaa siivoustaan sovelluksen sisällä ja syö tarpeettomasti kaistaa, jota throttlauksella koitetaan ilmeisesti rajoittaa vielä. API dokkari antaa perusteet, mutta seassa on muutamia mainitsemiasi virheitä/outouksia, sekä paljon kuuluisia MagicNumbereita, joille voisi olla ihan hyvä saada selitys. Tuo 300ms pyyntöväli sekä throttlaus on myös ongelma kun aletaan kyselemään noita metadatoja.

Hyvä tietää tuo delete komennon homma... Jos on noin, niin **** hit the fan tilannetta odotellessa, kun sarjakansio vetää itsensä pöntöstä alas...

Omalta osalta olen juuri päättänyt pitkähkön keskustelun parin kontaktini kanssa, koskien sopimuksen sisältöä ja siihen upotettua lakijargonia. Koostan juuri tästä keskustelusta tekstiä, ja voin jo nyt sanoa, että sisältö sai gdpr ja sopimusasioista tietävät kontaktini hermostuneiksi. Varsinkin kun kyseessä todellakin on sitova sopimus ja se on kirjoitettu B2B asenteella. Ja sopimus astuu todellakin poikkeavalla tavalla voimaan, ei allekirjoituksella, vaan sillä, että jaat sovelluksen käyttöön.

Palailen tuon keskustelun tuloksista vielä tämän päivän aikana, kun saan kirjoitettua kunnolla auki ja mahdollisimman kliinisesti ja objektiivisesti. Faktoina siis.
Käyttäjätaso 5
Näin. Julkisella keskustelulla projektit mahdollistuvat, toisin kuin Elisan evästämällä privaatti pönötyksellä. 😃
Käyttäjätaso 3
Haluan tässä kiittää kaikkia teitä ahkeria koodareita ja kaikkia muitakin, jotka omalla ajallanne olette pyrkineet ja pyritte edelleen etsimään ratkaisua tähän ongelmaan. Toivottavasti sellainen löytyy ja ratkaisu tällaisen perushemmonkin, joka on pihalla (lähes) kaikista koodauksen hienouksista, tilanteeseen Elisa Viihteen käytössä. Tsemppiä! 🙂
Käyttäjätaso 7
Lappimiäs kirjoitti:

Kyllä tässä varmaan pitää pyytää api dokumentaatiota ja koodata joku tallenteiden lataus ohjelma kun ei sultin hommeleista tuu mitään. Mitä tohon sopimukseen tulee, onhan se paha mutta pystyy VARMASTI jotenkin duunaamaan sillain että everything is alright. pitänee pyytää äpi dokumentaatiota.


Postaas tänne se dokumentaatio ja kai sulta nyt toimivan applikaation sais vielä tän viikon sisällä?
Vai meneeks ens viikolle?

Kaikki, onkos siin dokumentaatiossa joku NDA?
Jos on, niin mistä kandeis katella anonyymiä versiota siitä?
Käyttäjätaso 5
toke kirjoitti:


Kaikki, onkos siin dokumentaatiossa joku NDA?
Jos on, niin mistä kandeis katella anonyymiä versiota siitä?



Ei ainakaan tietääkseni ole NDA;ta. Tai ainakaan mitään sen kaltaista ei ole vaadittu allekirjoittamaan.
Käyttäjätaso 4
Minun mielestä @ssulti kirjoitti varsinkin ytimekkäästi mitkä ongelmat ovat sopimuksessa:


- Jos asiakas (te arvoisat katsojat), joku viranomainen, oikeuksien haltia tai joku muu taho vaatii auditointia, on se suoritettava 3. tahojenkin. Omalla kustannuksellaan. Ulkopuolisen suorittamana. Arvatkaapa kustannus?
- Jos jotain sattuu, kehittäjän tulisi huomata se 24h sisällä ja ilmoittaa Elisalle (ehkä onnistuu webbipohjaisessa palvelussa), mikä on aika vaikeaa näin työpöytäsoftaa tekevälle.
- Elisa varaa sopimuksessa oikeuden siirtää kaikki kustannukset ylläolevista suoraan kehittäjälle.



Eli vaikka sovellus ei käsittele henkilötietoja ollenkaan, minä voin joutua maksamaan auditointia missä todetaan että "juu, pitää paikkaansa, ei henkilötietoja täällä".
Käyttäjätaso 5
Laitetaan nyt vähän teknistäkin kommenttia väliin, kun vielä mutustelen tuota lakikuviokeskustelua kasaan... Juu, se on pitkä teksti.

Sain tuotantopurkkia, kyllä - meillä ei ole testiympäristöä tarjolla, potkimalla selvitettyä muutaman jutun liittyen jo muutamaan kertaa kommentoituun kasioiden hakuun. Saa ne haettua per taso ja per kansio, mutta olisi tämänkin tietty voinut Elisan puolelta joku dokumentoida... Eikös?

Mutta itse tektip;

Pääkansio, sisältäen pelkän päätason kansiot:
GET /rest/npvr/folders?platform=external&appVersion=1.0

Kansion sisältämät kansiot ID;n perusteella;
GET /rest/npvr/folders/00000?platform=external&appVersion=1.0
00000 = folderId

Eli jätetään se maaginen V=n.n osuus pois, niin API toimii ihan eri tavalla kuin mitä dokumentin mukaan mennessä toimisi.

EDIT!Tallenteiden kohdalta löytyi myös vastaava pyyntö ladata vain kansion tallenteet (tulevat ja valmistuneet):

GET /rest/npvr/recordings/folder/00000?v=2.1
00000 = folderId

Ja toki kertauksena se, että se v=2.1 optiolla varustettu recordings pyyntö palauttaa 50 seuraavaksi poistuvaa tallennetta oman penkomisen mukaan, jos haluaa kaikki kerralla (juu, kaikki tallenteet mitä on ja on ollut joskus, sisältäen itselläkin 2011 leimoilla olevia...):

GET /rest/npvr/recordings

Eli taas otetaan magicnumber v=n.n pois pyynnöstä ja rajapinta tekee ihan toisin kuin dokumentaatio kertoo.

Itseä tämä havainto ei enää auta Mac version 1.x kanssa, kun olen jo muuttanut eViihteen toiminnan cacheamaan kansiorakenteen olioina muistiin ja päivittämään vain tarpeen tullen. Windows version koodeihin koskiessa tämä on helpottava tieto, mutta se sitten joskus myöhemmin, jos muuten asiat menevät eteenpäin. Mutta jos jotakuta auttaa, niin ollos hyvä.

Edit...

Jatkoin rajapinnan kiusaamista JSONQuery softalla, wildcard tallennusehdot saa kun saakin pyydettyä ilman että tarvitsee parsia koko folder-pyynnön kansio kauhua. Pyyntö muuten kuin dokumentissa, mutta PUT -> GET ja tietysti ilman mitään PUT pyynnön alla listattuja optioita.

GET /rest/npvr/recordings/wildcard?v=2
Käyttäjätaso 5
ssulti kirjoitti:

Tallenteiden kohdalta löytyi myös vastaava pyyntö ladata vain kansion tallenteet (tulevat ja valmistuneet):

GET /rest/npvr/recordings/folder/00000?v=2.1
00000 = folderId



Tämän kanssa tarvitaan maagista numeroa 0 folderId;ksi, kun haetaan pääkansiossa (Tallennekansio) olevia tallenteita.

(Editointi näköjään lukittuu tietyssä ajassa... kiva.) 😛
Käyttäjätaso 1
Mä ihmettelin noita rajapinta kyselyitä juhannuksena ja päädyin samoihin juttuihin ssulti kanssa. Harmi että jouduit tekemään samat kokeilut "uudelleen". En vain uskalla jakaa noita koodeja tässä vaiheessa.
Perhe on tykännyt kun KODI:sta saa taas elisan videot näkymään kivasti ilman viiveitä.
Siinä mielessä tuo uusi API ja dokumentointi on hyvä juttu.

Yhdistelemällä API dokkarin tietoja(syntakseja) keskenään saa sieltä lisää tarvittavia käskyjä.
Turhaa tietty tämä käänteinen suunnittelu. Elisa oli API dokkaria täydentänyt mutta vain EPG-lisäyksillä vaikka heille tuosta hakemiston sisältö käskystä laitoin viestiä yli viikko sitten. Eivät ole jaksaneet vastata.

Ainoa mikä tässä vielä tuon API:n kanssa mättää on tuon 50 talleenteen raja hakemistosisältö kysymyksessä. Tosin saahan sieltä 100 kun pyytää tallenteet aikajärjestyksessä eka vanhat ja sitten uudet. Se riittää mulle tässä vaiheessa.
Syntaksi ei ole kumminkaan lähes sama kuin Web liittymässä(aikaisemmin elisalainen jakoi ohjeen webbi version monitorointiin). Sieltä apinoimalla saatte nuo aikajärjestykset ja muut parametrit kyssäreihin. Näin en kerro syntaksia mutta kerron kumminkin 🙂
Käyttäjätaso 5
Rellu kirjoitti:

Elisa oli API dokkaria täydentänyt mutta vain EPG-lisäyksillä vaikka heille tuosta hakemiston sisältö käskystä laitoin viestiä yli viikko sitten. Eivät ole jaksaneet vastata.



Ai sitä on päivitetty noiltakin osin. Oikein hauskaa vain, että eipä sieltä ole vaivauduttu päivittämään dokkareita meille muille jo aikaisemmin dokkarin saaneille. 😠

Rellu kirjoitti:

En vain uskalla jakaa noita koodeja tässä vaiheessa.



Itse olen tulkinnut tuota sopimusta parin noihin asioista perehtyneen henkilön kanssa tänään, että varsinaisesti API;sta keskustelu ja siihen liittyvistä teknisistä asioista julkaiseminen ei aktivoi mitenkään tuota tietosuojasopimusta, joka on saanut porukan takajaloilleen. Se tulee voimaan vasta, kun sovellus julkaistaan julkisesti ladattavaksi - tai näin siitä saa ymmärrettyä.

Eli teknistä speksiä vain julki. Jos ei saa, niin Elisa varmaan ottaa mopin käteen ja poistaa postaukset. :8
Käyttäjätaso 4
ssulti kirjoitti:

Pääkansio, sisältäen pelkän päätason kansiot:
GET /rest/npvr/folders?platform=external&appVersion=1.0

Kansion sisältämät kansiot ID;n perusteella;
GET /rest/npvr/folders/00000?platform=external&appVersion=1.0
00000 = folderId

Eli jätetään se maaginen V=n.n osuus pois, niin API toimii ihan eri tavalla kuin mitä dokumentin mukaan mennessä toimisi


Kun olisi tämä siinä dokumentaatiossa mainittu, olisi jokunen tunti säästynyt. Tallenteiden haku kansioittain sentään onnistui kokeilemalla, mutta tuo mahdollisuus v=n.n:n poisjättämiseen ei juolahtanut mieleenkään.

ViihdeX Media Manager alkaa muuten piakkoin olla siinä määrin valmis, kuin se nyky-APIa käyttäen (ainakin minun saamani dokumentaation perusteella) on mahdollista. Julkaisun estäviä ongelmia ovat lähinnä seuraavat:

Rellu kirjoitti:

Ainoa mikä tässä vielä tuon API:n kanssa mättää on tuon 50 talleenteen raja hakemistosisältö kysymyksessä.


asmandos kirjoitti:

Eli vaikka sovellus ei käsittele henkilötietoja ollenkaan, minä voin joutua maksamaan auditointia missä todetaan että "juu, pitää paikkaansa, ei henkilötietoja täällä".

+ pari muuta ssultin yllä mainitsemaa asiaa GDPR-sopimuksessa.
Käyttäjätaso 5
Qotscha kirjoitti:

Kun olisi tämä siinä dokumentaatiossa mainittu, olisi jokunen tunti säästynyt.



Kuten myös. Meni muutamakin ilta ja yö muutoksiin. Jos nämä olisi ollut tiedossa jo heti alussa, niin itseltäkin olisi säästynyt helposti useampiakin tunteja...
Käyttäjätaso 5
Mac version kanssa tehty etenemistä, YouTube linkissä demo missä mennään tällä hetkellä. Paljon editointia, lisäystä ja poistoa puuttuu, mutta perusasiota toimii jo...

https://www.youtube.com/watch?v=Jvd38_Tmd94
Käyttäjätaso 3
Jos asiakas (te arvoisat katsojat), joku viranomainen, oikeuksien haltia tai joku muu taho vaatii auditointia.

Auditoinnista voisaada kustannukset , kun laittaa maksulliseksi ohjemiston, jos muuten ei onnistu, jostain se euromäärä tarttee tulla. On sitten sitä peli varaa, jos alkaa kikkailu.

Onhan ohjelman tekijä, ja julkaisija, noilla tiedoilla aika hyvä saalis.
Ainakin itse olen, olemattomimmistakin ohjelmista maksanut 20€
ja jos laskee että 2000 x 20 voisko olettaa että , riittää.??
Käyttäjätaso 1
Olen seurannut keskustelua ja viime aikoina on tullut puhetta sovellusten muuttamisesta maksullisiksi.
Itse olen valmis maksamaan toimivasta Windows eviihde versiosta. Koodajat tekee kovasti töitä yhteisen hyvän vuoksi ja sitä kannattaa arvostaa eurojen muodossa
Käyttäjätaso 5
Maksulliseksi viemisen tuoma rahallinen hyöty, jos viedään esim Applen tai Microsoftin kauppaan tuottaa kaupasta riippuen myyntihinnasta noin 70% myyjälle, 30% jää kaupan pitäjälle. Tästä lähtee tämän jälkeen riippuen miten rahat ottaa ulos helposti se 45-50% (toiminimellä toimiessa 24% alv ja verot). Toki kikkailuja on, joilla näin ei käy.

Otetaan teoreettinen, myyn eViihde sovellusta Microsoftin kaupan kautta 10e (eli 9.99e siis). Jokaisesta myynnistä lähtee 3e tuonne rapakon taakse. Sen jälkeen 7e summasta tullaan vetäisemään asioista riippuen 3-4e. Eli käytännössä käteen jää lähihuoltsikan kahvikupin ja eilisen munkin hinta.

Tästä syystä en ole lähtenyt itse mihinkään kauppaan tuota viemään. Jotta kauppoihin edes saa, on oltava developer ja muut lisenssit. Applen kohdalla se on 99e/v, Microsoftin kohdalla en muista suoraan. Mutta kun Community version VS;llä ei saa tietääkseni kaupallista tehdä, niin hupsista heijaa, sinne meni se 300-900e riippuen miten lisenssin VisualStudioon hankkii.

Eli tuhannella myydyllä kattaa ehkä alkukustannukset, kun viimeinen tiedetty käyttäjämäärä on noin 2000 pintaan ja näistä tuskin kuin se 10% on valmis maksamaan... 200 myydyllä ei pitkälle mennä.

Ja kyllä, olen laskenut näitä moneenkin kertaan useammankin projektin kanssa, että missä kohtaa on taloudellisesti järkevää viedä maksulliseksi ja missä ei. Valitettavasti eViihteen kohdalla se ei ole koskaan ollut taloudellisesti kannattavaa...

Eli virallisesti en tule koskaan pyytämään rahaa eViihteestä. En ennen kuin on varmaa, että käyttäjäkanta on lähempänä 20 000;ta ja ostajia sovellukselle on vähintään se 2500+.

t. kaupallisen koulun kauhut kokenut (Merkonomi 1996 + YO-Datanomi 1998, 5.5v laskentatoimea ja kirjanpitoa kärsitty...)
Käyttäjätaso 5
Olen valmis maksamaan tämän uuden pskAPIn kanssa toimivasta Elisa ViihdeX Media Managerista tai vähintään vastaavasta, jolla voi taistella jatkuvien uusintojen poistamisesta. Saa olla aika korkea hinta, että se estäisi ostamasta.
Käyttäjätaso 7
ssulti kirjoitti:

Maksulliseksi viemisen tuoma rahallinen hyöty, jos viedään esim Applen tai Microsoftin kauppaan tuottaa kaupasta riippuen myyntihinnasta noin 70% myyjälle, 30% jää kaupan pitäjälle. Tästä lähtee tämän jälkeen riippuen miten rahat ottaa ulos helposti se 45-50% (toiminimellä toimiessa 24% alv ja verot). Toki kikkailuja on, joilla näin ei käy.

Otetaan teoreettinen, myyn eViihde sovellusta Microsoftin kaupan kautta 10e (eli 9.99e siis). Jokaisesta myynnistä lähtee 3e tuonne rapakon taakse. Sen jälkeen 7e summasta tullaan vetäisemään asioista riippuen 3-4e. Eli käytännössä käteen jää lähihuoltsikan kahvikupin ja eilisen munkin hinta.

Tästä syystä en ole lähtenyt itse mihinkään kauppaan tuota viemään. Jotta kauppoihin edes saa, on oltava developer ja muut lisenssit. Applen kohdalla se on 99e/v, Microsoftin kohdalla en muista suoraan. Mutta kun Community version VS;llä ei saa tietääkseni kaupallista tehdä, niin hupsista heijaa, sinne meni se 300-900e riippuen miten lisenssin VisualStudioon hankkii.

Eli tuhannella myydyllä kattaa ehkä alkukustannukset, kun viimeinen tiedetty käyttäjämäärä on noin 2000 pintaan ja näistä tuskin kuin se 10% on valmis maksamaan... 200 myydyllä ei pitkälle mennä.

Ja kyllä, olen laskenut näitä moneenkin kertaan useammankin projektin kanssa, että missä kohtaa on taloudellisesti järkevää viedä maksulliseksi ja missä ei. Valitettavasti eViihteen kohdalla se ei ole koskaan ollut taloudellisesti kannattavaa...

Eli virallisesti en tule koskaan pyytämään rahaa eViihteestä. En ennen kuin on varmaa, että käyttäjäkanta on lähempänä 20 000;ta ja ostajia sovellukselle on vähintään se 2500+.

t. kaupallisen koulun kauhut kokenut (Merkonomi 1996 + YO-Datanomi 1998, 5.5v laskentatoimea ja kirjanpitoa kärsitty...)


Näist kandee siis tehä crowdsourcingin, niin rahat kerätään ennen työtä ja mahdollisia tappioita.
Käyttäjätaso 3
Rahat kerätään ennen työtä ja mahdollisia tappioita.

Eli siis, ennen työtä [ Koodaus työtä ? ] ei uppoo jakeluun.... entäs, jos sitä ei oo mahdollista edes julkaista... ????? Vaan koodaajat tekee sitä omaan käyttöön " ilman julkaisua ", enkä ihmettele, jos siitä kaiken maailman , maksuja voi olla tulossa.
Käyttäjätaso 1
ssulti kirjoitti:

Päivittelen jatkossa tänne tilannetta; http://www.eviihde.com

Tuolla on karkea lista mitä on tehty ja mitkä toimii. Myös jatkossa tulen tuonne kommentoimaan, jos jotain osuuksia jää pois API;n rajoitusten vuoksi.


Aivan mahtavaa! 😃