# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 13
# self = https://watcher.sour.is/conv/i3wynfa
@jdtron I'm wondering whether we should split out the lextwt parser library that @xuu wrote that yarnd uses for parsing. If we split this out into a library (_actually you can already import it_) then both twet and yarnd can share the same parser - thus reducing efforts and sharing the same behaviour and bug fixes 👌 -- I _believe_ even @lyse has managed to import lextwt via a C-extension with his Python written tt client too 👌
@jdtron I'm wondering whether we should split out the lextwt parser library that @xuu wrote that yarnd uses for parsing. If we split this out into a library (_actually you can already import it_) then both twet and yarnd can share the same parser - thus reducing efforts and sharing the same behaviour and bug fixes 👌 -- I _believe_ even @lyse has managed to import lextwt via a C-extension with his Python written tt client too 👌
@prologic I've rewritten the parser in twtr approximately 4 or 5 times in the past few weeks, I haven't quite worked out how to implement all of the spec extensions yet, so I reckon having a common parser would be fantastic! That being said, for the sake of diversity it's probably also good to have a couple of implementations floating about.
@prologic I've rewritten the parser in twtr aproximiately 4 or 5 times in the past few weeks, I haven't quite worked out how to implement all of the spec extensions yet, so I recokon having a common parser would be fantastic! That being said, for the sake of diversity it's probably also good to have a couple of implementations floating about.
@<~duriny https://envs.net/~duriny/twtxt.txt> Well on the point of diversity, we _used_ to have a regexp based parser, but in practise we found that it was hard to do some things using ordinary regular expressions so we dropped it for a proper lexer/parser.
Let me know how you'd like to proceed or if you think we should just split out the lextwt parser anyway 🤗
@<~duriny https://envs.net/~duriny/twtxt.txt> Well on the point of diversity, we _used_ to have a regexp based parser, but in practise we found that it was hard to do some things using ordinary regular expressions so we dropped it for a proper lexer/parser.
Let me know how you'd like to proceed or if you think we should just split out the lextwt parser anyway 🤗
Oh split it out for sure, the more the code is broken down into small pieces that do one thing well the better :)
i agree that lextwt is probably mature enough to have its own lib
i agree that lextwt is probably mature enough to have its own lib
@xuu Cool I'll try to do this in the coming days 👌
@xuu Cool I'll try to do this in the coming days 👌