Flutterby™! : Non-browser tools 2001-12-12 18:07:16+00

Non-browser tools

2001-12-12 18:07:16+00 by Dan Lyke 24 comments

In the latest thread on education, Ziffle asked: "Dan: how are we supposed to get wordy if you keep the edit box so small?"

I guess I could make the size of the edit box settable via cookie, but the real long-term solution seems to be building some tools so that people can use their own favorite editors or other tools divorced from the browser to interact with Flutterby.

The Manila-RPC interface seems to be one that other people are supporting, but doesn't map to Flutterby's internal structures nicely. I've been playing with some client ideas in Perl::Tk. Is anyone else out there interested in this problem either from a client side or a server side? I got a resounding nothing to my Storm Cellar proposal.

'cause I find more lines than the 16 gets really annoying, because web browsers have that whole double-scrolling thing going (the inner box scrolls, and the page scrolls). Which is why I'd want to make it a cookie option.

But my usage pattern is also such that if I'm writing a longer rant I'll write it in my editor of choice and copy it into the comments text box.

Maybe I'll try expanding it to 25 lines or so tonight and see how annoying that ends up being.

Oo! Oo! I can [maybe] help with this. I've been establishing something similar for my own home page. I've written an application in Visual Basic (stop laughing) that tunnels through SSH to a remote MySQL server and allows me to add/edit my News and What's New entries. It's still in the early stages, but it's functional and live. The next step (assuming I want to make it available to others) is to port it to the Mac with REALBAsic and linux as soon as the GnomeBasic and KBasic projects reach a stable point.

Stormcellar looks like a great idea, and I'd be happy to help with it where I can. But I tend to be more of an in-the-trenches developer. I'm not one for developing new idioms, ideologies and/or protocols. Too vague and amorphous for me. I prefer having my hands on concrete structures.

Perhaps I'm just stuck in the past but I'm still enamored by your old Newwwsboy interface, but then, I've got no problem with the size of your textbox. Maybe I'm just not that wordy. ;-)

I just realized i have my 19 inch screen set so the whole text box becomes small on the screen - I can see a normal screen (whats normal?) user might want it like you have it.

Ziffle: I tend to use tiny browser windows, that's probably the usage difference. Sounds like a cookie config option is necessary. Actually, anywhere there's a text box and you're already logged in I've probably already checked user info. Huh, lemme pursue that idea, make it a pref...

Larry: The old interface became an issue with editing, and I can't figure a good way to make it work for comments.

Shawn: What I wanted with Storm Cellar was something quick and dirty that would let sites share log-ins. I just couldn't get anyone running another site with comments to sign on.

And VB type apps is exactly what I'm talking about. Any chance you could think about abstracting the interface from MySQL out a bit? Maybe a way we can use SSL/https for the encryption so it's easy to use unencrypted streams and implement in web server bits? For all its flaws, XML-RPC or similar?

Dan, I understand that the email interface to Newwwsboy had its limitations but I never understood why you didn't keep that interface along with the one you have implemented now. Between the two you have some very powerful capabilities.

I guess I'm thinking in terms of how I might like to interface with my own journal. Being able to jot down thoughts on my Palm and those thoughts wind up on my journal the next time I sync is very appealing to me, hence my continued fascination with the Newwwsboy interface. I'm also trying to figure out what else I might use in an editor that I don't already have available to me. So far I don't see anything.

Dan: The MySQL interface is provided by MS's ADO layer, which then talks to an ODBC layer (MyODBC), so it's already abstracted. As long as I have an ODBC driver for the given target database, I can easily tune the app to use that.

I'm not sure how I would implement SSL or something similar. With VB, I specify the server to connect to and it does so using the standard network connection methods. So tunnelling works well. If SSL could be made to work in that context, then sure. But this app (and most all VB apps) work at a much higher level, with various layers of abstract network communication below that - hidden away from our sensitive, delicate Visual Basic eyes.

It looks like the level you're suggesting coding at would require that I re-invent the wheel (ADO), at which point I might as well do it in C++.

But I've only started to look at the technologies you mention (such as XML-RPC), so I may be misunderstanding their application. I'm certainly open to continued discussion on this front.

Oh, and while I think being able to manage content in a non-browser way is cool ;-), I must confess that I don't understand the initial problem that spawned this thread.

The edit box grows a scrollbar if you've got more lines than it can visually display. What's the problem?

Dan, you've written this in Perl, right? Check out SOAP::Lite (which has XML-RPC, as well). It wasn't that hard for me to take the functions I had and make them accessible via SOAP.

I've used the Frontier::RPC2 modules before, I'll have to look at SOAP::Lite, but, of course, the real issue is how to build an effective non-browser UI for this. What I really need is someone else doing similar hacking so that I don't feel like I'm just building ridiculous stuff for my own use, but I don't know how to get over that critical hump to get started playing with shared code, either.

I'll try to read through these ideas tomorrow and actually put some coherent proposals on the table.

Actually, I've been pondering how I might do what I'm looking to do on my Palm using Avantgo picking up a custom channel containing a form of my own design. I'll look more into the PalmWiki thang though. My first go at it I kept stumbling over all the ikis and gave up on it. I was kind of rushed for time.

Just a comment, Shawn: If you're using ADO -> MyODBC you've got an extra layer (the MS OLE DB provider for ODBC drivers) that you can avoid by using ADO -> MyOLEDB. Won't cost you anything in abstraction to switch, though of course you should still test to make sure the OLE DB provider is capable.

Dan: You can always convert everything over to ASP.NET and use SOAP....naw, I didn't think so either.

Hmmm. I'm not laughing, Shawn, because I've been mulling over a design for a similar project. I recently built what is basically a custom FTP client in REALbasic to maintain my "photo of the day" page. It loads pictures from my digital camera, scales & rotates them, and uploads them, all in pretty much one step. It has made life a lot easier. Since that I've been thinking of developing a similar app to let me add text snippets to the site. Throwing together an RB app that would let you write reams of text and then upload it as a text file somewhere would be a matter of perhaps a couple days' spare-time hacking.

Another simple approach might be to put a CGI on the flutterby server and have the client push data into it with an HTTP POST. That'd be nearly trivial to code.

Mars, thats exactly what I had planned on doing when I got around to it (hovering around #257 on the todo list). Writting a client in in perl:tk or C++ and having it post to flutterby. The cgi on the server already exist. All my flutterby cycles are going into the game code now but I'll get around to it if nobody beats me to it (read this as I dare any of you to pop out a client)

todd: Give me the cgi and the POST names and I'll see what I can whip up. Don't expect that I'm familiar with the inner workings of Flutterby, 'cause I'm not ;-)

Mike: Thanks for the tip. Didn't know about MyOLEDB. I'll give it a try. Maybe it'll get me around my one big issue with MyODBC - apparently, I can only have one open connection at a time.

Dan: I took a closer look at XML-RPC and if I'm understanding the concept correctly, this should work fine - although it might be overkill. I also like Mars' idea of pushing it through HTTP POST (which would allow us to use SSL, right? Oh, wait... that would mean I'd have to code the client with SSL support, right? Hmmm...)

Mars: Very cool about your photo of the day setup. The text snippets thing is exactly what I'm doing (although they're stored in a database). You can see them in action (so to speak - it's transparent to the visitor) on my web site. The Personal News and What's New content on the front page are handled this way. I just added the first new blurb this morning in fact. Took me all of 2 minutes - Gawd I love coding :-)

Larry: I probably still have the transitional script around somewhere, maybe I'll try to hack something in so that it has some sort of smarts about who's sending to the page and set it back up.

I also need

to get the rants section back up, breaking my thoughts up small isn't helping the flow of the site.

Shawn et al: XML-RPC and SOAP are just other ways of encoding POSTs. But I'm also happy to do something closer to, say, the way Flash likes to interact with CGI scripts, just make everything form-encoded. The nice thing about doing it with that layer is that it allows an application to enforce things that the database might not have the provisions for, like field level access and database integrity which can't be implemented just with triggers.

Mars & Todd: We need to find a way to coordinate on this, 'cause I've got two apps on my laptop that are mid-way to doing most of the image management stuff, but I haven't put it all together and combined it with the uploading yet.

My home-coding efforts are playing with some game ideas for the next couple of weeks, and I've got some prep work to do in the next week that'll be cutting into my computer play time (ahhh, the joys of the midwinter marketing season), but I'll try to lay some code and specs out there and maybe we can find common ground to share work. Right now I'm using ImageMagick for the rescaling, scp for file transfers, and I'm playing with Perl::Tk and PostgreSQL for the interactive bits.

Hey! I got a great Idea let's set up a another flutterby_cms as a dev/test/staging sever and let people like Shawn hack away with worry of doing bad things to flutteby. I had full version a flutterby_cms running for a few months on the old sever without mishap so I am sure the new one will handle this. The bonus is that you could use the CMS as a development BBS. we would need to replicate new dbase tables, set up a cvs tree, create a developer group & group permissions etc etc but I think it would be cool to open development for flutterby whatdoyathink?

todd: I could *so* go for a collaborative development setup. I've been eyeballing some open source projects that I might want to contribute to, but not ever having done that before I feel a bit overwhelmed at just jumping right in the middle of a major project. Something like this would be more my speed - and give me valuable experience in working in such an environment ;-)

Dan: Uh... Flash can interface with CGI?? I know nothing about Flash other than people can use it to make purty mooving picshurs.

We're talking about pictures now? I'm starting to get confused. What I'm concentrating on at the moment is the ability to post comments to the site with the use of a local app. Certainly there are further applications for the framework, but my focus-of-the-moment was to start there.

Lemme diddle with CVS this weekend, make sure you can check out the Flutterby CMS source and see if it's something you wanna diddle with. And I'll see if I can slap together a simple API of some sort.

I never thought I'd be saying this, but Flash rocks. Well, it sucks too, and hard, but not for the reasons I originally thought. Most of the ill-deserved bits of its suck reputation are based on what people use it for. It has a JavaScript like language that has semi-decent facilities for reading and writing variables from CGI. Back when Coyote Grits was a going concern Todd and I had a rather nice GANTT chart editor in Flash

as part of a project management system we were playing with.

The real suckiness comes from the development environment, which makes it extremely hard to organize the sort of larger projects it seems possible to do.

<giggle> Shawn you have in me stiches over here. Calling Dan out on FLASH! and making him defend it has made my whole week...just a sec another giggle fit coming bwahahahahaha.. ok ok better now. Don't worry about flash right now. I think you have totally the right concept of what to do. Dan owes me lunch so if something doesn't happen this weekend Dan & I will meet next week and figure it out. I'm feeling like sushi anyhow (coyote grits joke). So what I suggest Shawn is play with a framework your comfortable building an editor in and if you have any questions fire them off to Dan or I in email or even post them here...