What's Next For Nextdb?

[Eric Dorman]

Hey guys,

What's next in the future for Nextdb?

I know Geoff and I have been talking about extending the APIs in
Python and other langauges,but what else are you guys planning to role
out in the future?

Thanks & God Bless,
Eric

[Geoffrey Hendrey]

REST apis are coming. I've posted two videos on the wiki.

From my perspective, data visibility and data import are two areas we
need to improve.

'data visibility' means you should easily be able to find any row no
matter how many GB are in a table. To address this I think we can
frame the searchable/sortable REST tables, that I showed in the video,
into the existing admin. Jeremy also pointed out a data visibility
issue WRT relationships. We need to support that too.

To address ease of import, I've implemented csv POST so you can just
post CSV files to your db and they automatically create a table.

Those things combined let me easily squirt data into the db, and
immediately bang out a URL to an attractive, useful table. That's a
solid starting point that any user can comprehend and reach
immediately without writing js or any program at all. Looking to roll
those features to production this month.

At the risk of being long winded, one final missing piece. For me,it's
"gallery view". Real websites don't display tables; they use
galleries. I.e. Reformatting the content of a row into a visually
attractive, non-tabular, repeated motif. Think "news stories" or "blog
posts" or "product previews". Once we've made that easy ... I mean
BRAIN DEAD easy, then I think we'll be better positioned in the market.

That's what I think is in store for nextdb.

[Eric Dorman]

Wow, that is a mouth full.

So the REST apis are coming and that's great news.

Do you still think we should make a goal for developing a Python api?

Thanks for the advice this morning on the other post I really
appreciate it Geoff.

Thanks & God Bless,
Eric

On Oct 13, 7:12 pm, Geoffrey Hendrey <geoff.hend...@gmail.com> wrote:
> REST apis are coming. I've posted two videos on the wiki.
>
>  From my perspective, data visibility and data import are two areas we  
> need to improve.
>
> 'data visibility' means you should easily be able to find any row no  
> matter how many GB are in a table. To address this I think we can  
> frame the searchable/sortable REST tables, that I showed in the video,  
> into the existing admin. Jeremy also pointed out a data visibility  
> issue WRT relationships. We need to support that too.
>
> To address ease of import, I've implemented csv POST so you can just  
> post CSV files to your db and they automatically create a table.
>
> Those things combined let me easily squirt data into the db, and  
> immediately bang out a URL to an attractive, useful table. That's a  
> solid starting point that any user can comprehend and reach  
> immediately without writing js or any program at all. Looking to roll  
> those features to production this month.
>
> At the risk of being long winded, one final missing piece. For me,it's  
> "gallery view". Real websites don't display tables; they use  
> galleries. I.e. Reformatting the content of a row into a visually  
> attractive, non-tabular, repeated motif. Think "news stories" or "blog  
> posts" or "product previews". Once we've made that easy ... I mean  
> BRAIN DEAD easy, then I think we'll be better positioned in the market.
>
> That's what I think is in store for nextdb.
>

[Eric Dorman]

Do you still think we should make a goal for developing a Python api

along with the REST ones?

Geoff thanks for the advice in the other post today and you are right
I do need to focus on one idea and make like a simple app or the
Python API and just focus on that.

Nextdb is one it's way.

Thanks & God Bless,
Eric

[ibec]

How about an "admin console" that allows you to perform queries and
actions to maintain databases and tables?

[geoffrey hendrey]

We have been evolving the admin console. It now has a feedback link, which has been quite useful. We've logged dozens of issues per day on it over the last few days.

The REST features are now live! Here is an example of a public table accessible via pure REST.

http://www.nextdb.net/nextdb/rest/geoff/testchars/lines/style/newspaper-a

(here are a few examples of how you can search and sort)
http://nextdb.net/nextdb/rest/geoff/testchars/lines
http://nextdb.net/nextdb/rest/geoff/testchars/lines/line/contains/fire
http://nextdb.net/nextdb/rest/geoff/testchars/lines//pg/100
http://nextdb.net/nextdb/rest/geoff/testchars/lines/lrow/100


There are many operators for searching such as greater than, less than, equals, and several very simple DATE functions (mo,day,yr), all of which can be easily used in the URL like the one above.

You can retrieve the raw content out of columns by referencing the column name with an extension such as ".txt" or ".jpg"
http://nextdb.net/nextdb/rest/geoff/testchars/lines/row/100/line.txt
http://nextdb.net/nextdb/rest/dd/PHH/KIDS/row/1/photo.jpg


If you want to create a gallery instead of a table, you can associate an XSLT transform to create totally custom pageable web pages that simply recycle the page links generated by the standard REST table. That is done by passing the URL-encoded stylesheet URL into the REST URL as  a 'matrix parameter' like this:

http://www.nextdb.net/nextdb/rest/geoff/testchars/lines/style/newspaper-a;xslt=<your-URL-encoded-xslt-URL-here>

One of the cool things about the REST URLs is that you can access columns as files by giving them extensions. For example, when I wanted to put an XSLT online, I just put it in nextdb and access it like this

http://www.nextdb.net/nextdb/rest/dd/phh/config_files/row/1/xslt.xsl

The ease of storing XSLT, and applying it back to the REST tables, for me at least, seems like a pretty fun development paradigm.

I'll keep you posted on the REST features ... there is a lot I have omitted form this email.

-geoff