Extend some data models

[komar007]

Events currently contain only content and starting/ending dates.

@hapticastudio shouldn't we also have a short title to present on a list except for the long body which can be presented after clicking a particular item?

@KillaPL we should have logos in places. Any ideas how to implement this? Since they will be most likely very small, maybe they could be inlined in json in some ascii-friendly format?

In the future we will need images support in general (for places' descriptions and so on), so a separate resource will be useful just for them, unless you think we should embed everything somehow.

For me it doesn't really matter.

[lstrzebinczyk]

New events fields are already described here: #9. I'll check if having base 64 images is hard, but i don't really think so. Usually images are just a part of models they belong to.

[lstrzebinczyk]

There are 2 gems I know of to manage images. None of them, however, supports storing images as base64. We can't store images as images on heroku. It just doesn't allow it. I will try to work with carrierwave guys to send them a pull request with base64 support. Development of this part will have to wait.

[lstrzebinczyk]

Edit: Working with carrierwave might be a little bit too much. They probably will cry about other orms to support, other ruby or rails versions and so on. I will create something from scratch, but still not today.

[komar007]

Can't you just put the image data to the database and convert to base64 on demand? Or even serve as static binary content? If you need a hosting without limitations, there's no problem. I think one sensible solution here would be to store all the images which are part of the content in a single table as blobs. For simplicity's sake you could just provide all these images in json, converting to base64 on demand, just like other content. For logos, you can just use image_id field in Places and some special tags in descriptions, which I will just parse and substitute with proper images.

[lstrzebinczyk]

Did you read the email I provided? It states, that there is no point in playing with base 64. Not only we both have more to implement, but it ends being more data to send, which you cannot paralelize.

It's not as good idea as it seems.

[komar007]

I did. I don't see why there's not point. 33% average size increase is not a problem and the images will change rather rarely. So if they're not included in descriptions, but rather kept in a single table, they won't be sent frequently at all. Base64 is dead-simple to convert from and to. And if you think the size increase is no good, then I'll be fine with just images assigned ids to and sent separately as regular binary files + json metadata like {"images": [{"id":1234, "filename": "1234.jpg"}, ...]}. Then the mobile app will just download a list using updated_since, like everything else, and later download each added or modified image separately. I don't think we want to make extra dependencies on external cloud services. @hapticastudio should probably decide about that, but I think this just complicates the deployment and maintenance. After thinking about it for a while I think I'm leaning towards the second option (json metadata + binary images) to eliminate large payloads sent over the network at the expense of making more requests.

[lstrzebinczyk]

I will think of a best solution for data organisation. There's also the storage problem, and it's one for @hapticastudio to state some opinions. It's either we change server platform/move to dedicated server or store images in cloud.

I personally reccomend the cloud. It's easy to integrate as fuck, and cheap as fuck. Check the pricing: http://aws.amazon.com/s3/pricing/

[komar007]

I don't find any progamming obstacles with using amazon service, provided that:

1. @hapticastudio agrees,
2. metadata is provided with the whole content and updated_since capability,
3. individual images can be downloaded using simple http requests.

Still not sure if decentralizing the system is a good idea though.

[lstrzebinczyk]

I can provide 2 and 3. And I'm pretty sure, that decentralising the system is a pretty good idea; )

[hapticastudio]

I totally agree with komar007. Decentralising the system sounds like a hack - remember, that for example software will be able to install on dedicated server managed by our customer, decentralising it will make some problems with this issue.

[lstrzebinczyk]

Having a dedicated server is so 10 years ago...

Well in that case, no images until you buy a server : P

EDIT

Let me tell you a story about bookrage.com. It's an application made in 50 lines of code.They store images in aws, serve payments with some other app and do everything they can with external application. These days that's how you write good, cheap and reliable applications, you move as many features as you can to people that already do it.

[lstrzebinczyk]

Closing this, no actual issue to solve here.