Hey lets work togeather

[rocktavious]

Hello,

I just recently found out about this kit, but i've been writing my own alexa integration for django - it seems like there are a few core features that we could share between this package and mine. Would you be willing to work togeather on creating a library that both your project and my project use to handle those overlaps?

I've been working to isolate them in my codebase, have a look at everything under https://github.com/rocktavious/django-alexa/tree/develop/django_alexa/internal

It's amazing how we've basically come up with very similar tech to cover the boiler plate.

I think it would be cool if we could come up with a good shared base and make that a package that our two libraries could leverage, because i'd also like to extend support to other web frameworks like Flask IE Flask-Alexa etc

It would be great to have such a wide package array all using the same core lib:

• core lib (maybe "py-alexa")
  • Lambda Alexa
  • Django Alexa
  • Flask Alexa

Let me know what you think.

[anjishnu]

Sounds like a good idea!

But we probably need to flesh out the design a bit more to see how much of our codebases are reuse-able and whether the modularity is taking care of potentially different goals for these projects.

My project goal is basically to build that library - the Lambda and Server releases are just so that the library code is useful from the get go without complicated API docs.

[rocktavious]

It looks like the most common overlap in our projects is the ResponseBuilder related stuff.

I have a IntentsSchema class that uses a decorator to build up the intents, utterances and custom slots definitions based on your code. Seems like it would be useful to your project so you don't have to specify JSON files as an extra thing beside your code and then you'd just need to expose some commandline scripts from a setup.py "scripts" directive so that someone could use a commandline invocation to print out this introspected data.

The major hangup i see is this IntentsSchema relies upon a "Slots" class with class attributes assigned to it to parse the necessary data (which is also used as a validator of the data specifically in my project)

I'm not sure how that part fits into your library, but this is be very useful when extended to flask because it has a very similar model for serialization/deserialization as django does.

I would hate to have to write our own validation for each amazon slot field type, so maybe we could leverage something like https://pypi.python.org/pypi/marshmallow for your libraries validation and then use the django / flask specific ones for those libs.

The way i mixed this into the django lib was to have just a base class in the API and then in the django specific lib i make a class that mixes the serializer with my API's base class and then boom, the Intents Schema can introspect and generate the slots data. See - https://github.com/rocktavious/django-alexa/blob/master/django_alexa/api/fields.py

[rocktavious]

If amazon echo devs ever provide an API to upload skill definitions, i would add a helper class that uses my IntentSchema class to beable to upload this data so that skill definition could be auto registered, instead of having to use the web UI to do it.

[anjishnu]

Hi Rocktavious - sorry for the late reply - I was basically reworking the APIs for my codebase and simplifying them dramatically. I'm going to start looking into your code to figure out slots and intents now. I'm going to be looking into how to make this library more helpful in data generation, custom slot support, slot resolution (if alexa's ASR is not perfect). I'm probably going to go with an IntentSchema object which is a thin wrapper around the JSON representation so that it can be modified serialized and deserialized easily.

[rocktavious]

@anjishnu Any further thoughts? (sorry been on hiatus for a bit cuz of a new child)