What's the most important thing lacking in your Tcl toolbox?
Larry W. Virden
this or that to compete with this language or that framework.
That's not what this posting is about.
What this thread is about - hopefully - is identifying areas in which
you, as a tcl developer, have a need, but have been unsuccessful in
locating a solution.
Maybe it is a tool, or maybe it is an extension. Maybe it is an
example or a tutorial.
I hope that people feel free to post a quick note mentioning specific
needs that you have, and that other readers feel free to chime in with
suggestions for meeting those needs.
For instance, if someone were to post that they have a need for
calculating some specific checksum for some particular kind of data,
and someone else knows of a place where that kind of code might be
found, feel free to post the location. Or, if you don't know of a
place, but perhaps have created a page over at http://wiki.tcl.tk/
that discusses the issue, feel free to mention that.
What I hope to see in this thread are those undiscovered gems that I
am certain reside out there around the net, or strategies for solving
the problems, along with, hopefully, some updates on the wiki to help
future developers.
Thanks!
Bryan Oakley
> I hope that people feel free to post a quick note mentioning specific
> needs that you have, and that other readers feel free to chime in with
> suggestions for meeting those needs.
For me, the biggest missing piece is the ability to take the contents of
a text widget and print it out while retaining most of the formatting.
Every commercial product I've worked on that was implemented in Tk has
struggled with the lack of a decent printing solution.
--
Bryan Oakley
http://www.tclscripting.com
Synic
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
Most of the things on my wishlist are GUI interface matters:
* Some more of the Tk widgets going into Tile would be good. Having a
platform native spinbox and text widget would be useful, for example.
No doubt these things will be added in due course :-).
* A way to have a completely flat button widget in either Tk or Tile
on Mac OS X in button bars. Specifying -relief, etc, in Tk doesn't work
at present.
* Freshening some of the other Tile widgets on Mac. In particular,
notebook tabs are looking increasingly unusual.
* Handling of .icns files in the Img package could be handy.
* A standard API for handling printing. The back-end would be different
per platform in terms of setup, but, it would be useful to have a Tcl
script be able to call something like:
set lpt [::printer::use default]
lpt print $data
... and have the data sent down the wire to whatever's on the other end
in whatever way their OS handles it normally.
No need for info from per-platform printer dialogs, lets just have an API
which lets us manipulate them:
set allprinters [::printer::get all]
set lptinfo [::printer::get default info]
set allprintersinfo [::printer::get all info]
::printer::set default [lindex [::printer::get all] 0]
Bryan Oakley
> Larry W. Virden <lvi...@gmail.com> wrote:
>> What this thread is about - hopefully - is identifying areas in which
>> you, as a tcl developer, have a need, but have been unsuccessful in
>> locating a solution.
>
> Most of the things on my wishlist are GUI interface matters:
>
> * Some more of the Tk widgets going into Tile would be good. Having a
> platform native spinbox and text widget would be useful, for example.
> No doubt these things will be added in due course :-).
What's a "platform native text widget"? It's just a big white (or
whatever) square. Are you thinking about a bunch of built-in controls
for bold, italics, etc?
Synic
Nah. I mean, as in handling of the widget border, as far as 3D effect
and highlight colour go.
Even after matching highlight colours, etc, there's a noticeable
difference between the way borders are handled between the Tk text
widget and the single line ttk::entry widget. It's something especially
visible on Mac and present on Windows. Not too noticeable on X11, IIRC.
Bart
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
>
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
I have done great things with Tcl in the past so it is one of the most
complete tools that I have used. Having said that, I think the following
could be added and/or improved:
1) Increase the efficiency and flexibility of smtp and smtpd. Pehaps
this is
more of a tutorial type of thing.
2) Handling for other messaging protocols like instant messaging. Perhaps
this exists already and I am simply unaware of it.
3) Tutorials or introductory use cases for many packages (soap, tile,
etc.).
Is that 3 points or just one?
ped...@west.com
but...
1) writing TCL web serverices via SOAP is not at all easy.
G.Lester's 'Web Services For Tcl' is a start, but it only works for
tclhttpd.
The world is XML and SOAP 5 years ago and tcl is still lacking.
2) tdom8.1 is the best xml parser (but it's been sitting in CVS for 2+
years) and has no release date...
3) tcl 8.5 needs to be released.
Alan Anderson
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
Printing. For example, to produce a formatted report, I currently
resort to using HTML and a separate program. Printing graphics is still
problematic.
Michael Schlenker
> 2) Handling for other messaging protocols like instant messaging. Perhaps
> this exists already and I am simply unaware of it.
nased messenger for aols IM procotol (oscar8) and the jabber clients
tkabber and coccinella at least.
Michael
Darren New
> What's a "platform native text widget"? It's just a big white (or
> whatever) square.
Errr, not hardly. :-) On Windows, it has all kinds of features that
systems that reimplement text boxes on their own are missing (Tcl and
Firefox/Thunderbird being the ones that annoy me most).
--
Darren New / San Diego, CA, USA (PST)
The primary use of XML is as a technique
to avoid documenting your interchange formats.
sleb...@gmail.com
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
>
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
>
> I hope that people feel free to post a quick note mentioning specific
> needs that you have, and that other readers feel free to chime in with
> suggestions for meeting those needs.
>
> For instance, if someone were to post that they have a need for
> calculating some specific checksum for some particular kind of data,
> and someone else knows of a place where that kind of code might be
> found, feel free to post the location. Or, if you don't know of a
> that discusses the issue, feel free to mention that.
>
> What I hope to see in this thread are those undiscovered gems that I
> am certain reside out there around the net, or strategies for solving
> the problems, along with, hopefully, some updates on the wiki to help
> future developers.
>
This will sound like a broken record: Printing! At this stage I don't
care anymore about Classic Mac printing. Just support Windows GDI and
CUPS. Currently I use the GDI and Printer extension on Windows and
Canvas Postscript output and Ghostscript for other platforms but it's
clumsy to have to write printing related code twice. In addition the
Canvas + Ghostscript solution is clumsy in it's own right. Guiding
users to install Ghostscript can be tedious.
sp...@controlq.com
Is TkTable going to be part of 8.5 core?
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
Synic
> Bryan Oakley wrote:
>> What's a "platform native text widget"? It's just a big white (or
>> whatever) square.
>
> Errr, not hardly. :-) On Windows, it has all kinds of features that
> systems that reimplement text boxes on their own are missing (Tcl and
> Firefox/Thunderbird being the ones that annoy me most).
For me, it's not so much about features as presentation. Used amongst
the other Tile widgets, the text widget's border can look a little out
of place.
This sort of thing doesn't matter so much for users of X11 and Windows,
but, many Mac users are extremely anal about look and feel and can
dismiss an application out of hand on those grounds alone.
Arjen Markus
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What I hope to see in this thread are those undiscovered gems that I
> am certain reside out there around the net, or strategies for solving
> the problems, along with, hopefully, some updates on the wiki to help
> future developers.
>
> Thanks!
Something I miss (but I am working on that ;)) is an easy
way to wrap Fortran libraries (*). Critcl is a fine solution for
C and I know of SWIG. But what matters to me is a way to access
those thousands of Fortran (or FORTRAN (**)) libraries out there,
for instance the Netlib collection.
Another thing, more or less related, is this:
Suppose I have a library (either Fortran or C or ...) that I
access from Tcl and I would like to use Tcl to manage the
memory that is involved. That seems like a good idea to me,
but I do not know what is involved: how to make sure
it all goes well with reference counts, the moment in time, etc.
I guess, I would like a tutorial on that issue.
Regards,
Arjen
(*) Only a slightly broken record ;)
(**) Allow me this small bit of pendantry
davidn...@gmail.com
> 1) writing TCL web serverices via SOAP is not at all easy.
>
> G.Lester's 'Web Services For Tcl' is a start, but it only works for
> tclhttpd.
>
> The world is XML and SOAP 5 years ago and tcl is still lacking.
Sometimes if you ignore things long enough, they'll go away. It seems
that 'REST' is what people are talking about these days, and all that
is is HTTP.
Mark Janssen
Not to look for excuses, but do you know any (scripting) language that
supports printing for multiple platforms as a library or out of the
box?
Mark
Mark Janssen
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> What this thread is about - hopefully - is identifying areas in which
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
>
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
>
> I hope that people feel free to post a quick note mentioning specific
> needs that you have, and that other readers feel free to chime in with
> suggestions for meeting those needs.
>
> For instance, if someone were to post that they have a need for
> calculating some specific checksum for some particular kind of data,
> and someone else knows of a place where that kind of code might be
> found, feel free to post the location. Or, if you don't know of a
> that discusses the issue, feel free to mention that.
>
> What I hope to see in this thread are those undiscovered gems that I
> am certain reside out there around the net, or strategies for solving
> the problems, along with, hopefully, some updates on the wiki to help
> future developers.
>
> Thanks!
And to add my own 2c. What I have missed recently is http 1.1 (or at
least http supporting keepalives) this is required for some
authenticating proxies for instance. There are some changed versions
of the http package which include this, but it would be nice if the
core http supports it.
Mark
Torsten Reincke
> Maybe it is a tool, or maybe it is an extension. Maybe it is an
> example or a tutorial.
Printing! Printing in the core (or as an extension, but it must be
useable on all platforms)! Printing for the people!
And a BLT that works on all platforms and Tcl versions (Aqua, 8.5, and
such).
Torsten
Matthias Kraft
> The world is XML and SOAP 5 years ago and tcl is still lacking.
Stable languages do not need to rush after every hype. Once the hype
has settled take a look what is left and build something stable for
it.
XML is almost everywhere and we have tdom, which is flexible and
stable as far I am concerned. I cannot tell anything about SOAP
though.
> 2) tdom8.1 is the best xml parser (but it's been sitting in CVS for 2+
> years) and has no release date...
... you missed recent development here: we are approaching a 0.8.2
release: go for http://www.tdom.org/files/, download and test the
latest RC...
> 3) tcl 8.5 needs to be released.
Yes :-)
kind regards
--
Matthias Kraft
Software AG, Germany
Bryan Oakley
> Darren New <dn...@san.rr.com> wrote:
>
>>Bryan Oakley wrote:
>>
>>>What's a "platform native text widget"? It's just a big white (or
>>>whatever) square.
>>
>>Errr, not hardly. :-) On Windows, it has all kinds of features that
>>systems that reimplement text boxes on their own are missing (Tcl and
>>Firefox/Thunderbird being the ones that annoy me most).
>
>
> For me, it's not so much about features as presentation. Used amongst
> the other Tile widgets, the text widget's border can look a little out
> of place.
Out of curiosity, did you try packing the text widget inside a
ttk::entry or ttk::frame widget to get the desired look?
Bryan Oakley
>>Maybe it is a tool, or maybe it is an extension. Maybe it is an
>>example or a tutorial.
>
>
> Printing! Printing in the core (or as an extension, but it must be
> useable on all platforms)! Printing for the people!
Frankly, I'd be satisfied if we only had printing on one or two
platforms. And if we had two or three different interfaces, that would
be fine too.
I suspect part of the holdup is that someone may know a way to make it
work on one platform but not on others so nothing is done.
Yeah, it would be nice if we had a uniform, perfectly functioning print
command that worked cross-platform, but I'd rather have something less
uniform than nothing at all.
Larry W. Virden
I encourage everyone for whom printing is an issue to contribute
thoughts, problem areas, suggestions, etc. over at http://wiki.tcl.tk/printing
Neil Madden
> Darren New <dn...@san.rr.com> wrote:
>> Bryan Oakley wrote:
>>> What's a "platform native text widget"? It's just a big white (or
>>> whatever) square.
>> Errr, not hardly. :-) On Windows, it has all kinds of features that
>> systems that reimplement text boxes on their own are missing (Tcl and
>> Firefox/Thunderbird being the ones that annoy me most).
>
> For me, it's not so much about features as presentation. Used amongst
> the other Tile widgets, the text widget's border can look a little out
> of place.
Have you tried -highlightthickness 0? That seems to do the job for me on
OS X.
-- Neil
suchenwi
- ability to rotate text on canvas
- ability to rotate photo images (at least in 90-degree steps)
The second can be done in pure Tcl, but a solution on Tk's C side is
probably much faster.
minu...@hotmail.fr
a multi-platform SSH client library/package for tcl would be nice.
Donal K. Fellows
> Is TkTable going to be part of 8.5 core?
No. But any binary distribution of Tk without making Tktable available
too is a bit incomplete in my view. :-)
Donal.
Donal K. Fellows
> * A way to have a completely flat button widget in either Tk or Tile
> on Mac OS X in button bars. Specifying -relief, etc, in Tk doesn't work
> at present.
With Tile/Ttk it should be possible to do this by setting the right
style (i.e. if you tell a button to be a toolbar button, it should
look right for the style of toolbar buttons for the current theme). If
it doesn't work currently, raise a bug report. :-)
> * A standard API for handling printing. The back-end would be different
> per platform in terms of setup, but, it would be useful to have a Tcl
> script be able to call something like:
>
> set lpt [::printer::use default]
> lpt print $data
>
> ... and have the data sent down the wire to whatever's on the other end
> in whatever way their OS handles it normally.
The problems with printing are actually quite nasty. The problem is
that there are two totally different approaches to doing printing, and
Tk only supports one of them (and only partially at that!) While on
standard Unix systems printing is done by sending postscript into the
'lpr' program, on Windows printing is done by drawing using a special
context. And to cap it all, only the [canvas] supports postscript
generation anyway. Fixing it all requires *real* work.
> No need for info from per-platform printer dialogs, lets just have an API
> which lets us manipulate them:
>
> set allprinters [::printer::get all]
> set lptinfo [::printer::get default info]
> set allprintersinfo [::printer::get all info]
> ::printer::set default [lindex [::printer::get all] 0]
Oh, and the other problem is that different platforms have different
interaction styles (blocking vs. non-blocking) for their standard
dialogs. Messy!
Donal.
Donal K. Fellows
> Sometimes if you ignore things long enough, they'll go away. It seems
> that 'REST' is what people are talking about these days, and all that
> is is HTTP.
Sounds like we're about ready for the backlash against REST. :-) To be
a little bit serious, the problem with REST is that it's hard to
automatically understand the artefacts it deals with. In particular,
knowing how to synthesize URLs for document fragments is non-trivial;
there needs to be some way of marking such things up, but when that
happens you jettison the light-weight-ness of REST. To date, these
sorts of things have tended to be ignored by virtue of making
interfaces to the real REST part out of custom javascript, giving
mashups but no easy route to deeper integration.
And rumours of SOAP's death do seem exaggerated.
Donal.
Donal K. Fellows
Donal K. Fellows
> - ability to rotate photo images (at least in 90-degree steps)
I've got bits and pieces of this, but haven't had the time to
reformulate it into a decent piece of code. It's not *very* hard, but
it does take time and I've been short of that for the past few
years...
Donal.
Arjen Markus
wrote:
>
> Oh, and the other problem is that different platforms have different
> interaction styles (blocking vs. non-blocking) for their standard
> dialogs. Messy!
>
> Donal.
Not to mention the fact that the standard dialogue that
pops up on Windows when you print something depends on the
printer too. Try printing to a file for instance (as is often
needed when printing a picture so that you can import it
in a document):
Sometimes you can specify a file name (typing it), sometimes
a file selection dialogue pops up, sometimes you have no
control whatsoever and you have to guess where the thing
ends up!
(Okay, an inaccurate description, but that is at least
my experience: lots of variations and it is very hard to
control)
Regards,
Arjen
Peter Dalgaard
> I'm missing:
> - ability to rotate text on canvas
Me too. And proper clipping, at least to rectangular regions. (No,
putting a sheet on top with a hole in it is not quite good enough!
There can be multiple viewports.)
--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dal...@biostat.ku.dk) FAX: (+45) 35327907
Neil Madden
> Over the years, I've seen many people post about how tcl should have
> this or that to compete with this language or that framework.
>
> That's not what this posting is about.
>
> you, as a tcl developer, have a need, but have been unsuccessful in
> locating a solution.
There are relatively few areas for me these days. Some things I could
have done with recently:
1. A really good, fast, generic database API along the lines of the
interface provided by SQLite. (I started using SQLite but have now
switched to MySQL).
2. A good way of specifying, reading and writing binary file formats. I
currently hand-coded a Tcl parser for a complex 3rd-party binary file
format but it's a major bottleneck in my code (to be fair, mainly
because I'm not very clever about avoiding [seek]ing all over a 300MB
file). Having a generic C-coded file parser would be a major win (even
better if it can mmap() the file). Such a parser would typically be
based on offsets and byte (octet) counts rather than syntactic delimiters.
3. Packages for RDF and OWL - mainly thinking in terms of the data model
here rather than parsing (which is just XML). This should cover parsing
(mostly just XML parsing), generation (xmlgen/tdom), and querying: both
TBox and ABox queries (e.g., via a DIG interface).
4. Tk widget-wise a lot of what I want now exists: good OpenGL widgets,
TkHTML, TkTable, Tile, etc. I sometimes wish for a slightly higher-level
toolkit layer which takes care of a lot of stuff like setting up default
menu entries (About, Help, Quit, Save, Open etc) and setting up most of
the scaffolding for things like drag-n-drop, printing, etc.
-- Neil
Darren New
> For me, it's not so much about features as presentation.
Until the features are things like "everywhere I need to type text, it
works, except in the textentry boxes of *your* applications." Then the
features become a lot more important.
sleb...@gmail.com
> Torsten Reincke wrote:
> >>Maybe it is a tool, or maybe it is an extension. Maybe it is an
> >>example or a tutorial.
>
> > Printing! Printing in the core (or as an extension, but it must be
> > useable on all platforms)! Printing for the people!
>
> Frankly, I'd be satisfied if we only had printing on one or two
> platforms. And if we had two or three different interfaces, that would
> be fine too.
>
Actually, since the Mac, Linux and the majority of Unices out there
are using CUPS we really only need to support 2 platforms: Windows GDI
and CUPS. But I'd still prefer a unified interface for both. It's fine
to include platform specific commands for when you really need it but
for the most part I shouldn't have to worry about it when writing
quick hacks. Kind of like the file related commands and Tk.
Bryan Oakley
Oh, I agree that in an ideal world it would have a unified interface.
It's just that there are at least three problems to solve: solving the
printing problem on windows, solving the printing on CUPS-based systems,
and abstracting the interface so it works on both. If we omit that last
part, we've cut the problem down by 1/3 (give or take an order of
magnitude...). And if we can only solve it for one platform, printing
just on windows, or just on CUPS-based systems would still be a win.
My current hope is that tkhtml3 becomes production-ready some day and we
can leverage its ability to accurately render html and css. If we could
solve the problem of dumping the raw, rendered bits from a tkhtml widget
to a printer it would become a somewhat straight-forward exercise to
convert a text widget dump to html+css, feed it to a hidden tkhtml
widget, and then send that to a printer.
--
Bryan Oakley
http://www.tclscripting.com
Synic
My current "just adequate if the users don't look closely" solution is
keeping -highlightthickness 1 and changing the border colour to a similar
lightblue to platform native.
Unfortunately, Tk's border is unantialiased with square corners, platform
native is antialiased with rounded corners.
Synic
>> For me, it's not so much about features as presentation. Used amongst
>> the other Tile widgets, the text widget's border can look a little out
>> of place.
>
> Out of curiosity, did you try packing the text widget inside a
> ttk::entry or ttk::frame widget to get the desired look?
I didn't try ttk::entry one as I wouldn't imagine the ttk::entry could
be make itself appear active and trigger its blue border highlight if
it's the other Tk text widget that really *is* active.
I wouldn't think the ttk::frame widget would produce that platform native
antialiased rounded corner blue border when the text widget is
highlighted either. Same for ttk::labelframe.
Synic
> Synic wrote:
>> For me, it's not so much about features as presentation.
>
> Until the features are things like "everywhere I need to type text, it
> works, except in the textentry boxes of *your* applications." Then the
> features become a lot more important.
Oh, the features are important, but, I haven't found the text widget
lacking anything in particular that stands out for me.
My only beef with the text widget wanting to see it Tile-ified rather
than being left behind as we all move on from crusty old Tk widgets to
our shiny new themed ones...
Bryan Oakley
Instead of imagining it, spend a couple of minutes and try it. I don't
have an aqua machine handy or I'd give it a try. On windows the outline
looks right when I pack the text into a ttk::entry (with -padx 1 -pady
1), but ttk::entry widgets for me don't change appearance when they gain
focus so I can't tell what happens when focus goes to the embedded widget.
I bet you can make it work by manually controlling the -state option of
the ttk::entry widget when focus goes into the embedded text.
<shrug>
lahl...@student.miun.se
> As you can find SSH client library for python and Ruby,
> a multi-platform SSH client library/package for tcl would be nice.
I've played around a bit with this idea during the summer, although
I eventually concluded that driving command-line SSH would suffice
for my project. I did research the feasibility of it, however; it
turned out pretty much everything which I felt would be *hard* to do
in Tcl (DES, SHA, bignums) is already available in tcllib!
Neil Madden
Hmmm... are we talking about the [text] widget here or an [entry]? I
thought we were talking about the text widget, in which case all the
text widgets I can think of on OS X (i.e., areas displaying large
amounts of text for viewing/editing) don't seem to have any border at
all. Could you describe the situation in a bit more detail as I've lost
the context now.
-- Neil
Darren New
> Oh, the features are important, but, I haven't found the text widget
> lacking anything in particular that stands out for me.
Handwriting recognition? Speech recognition? Automatically popping up
the on-screen keyboard when it gets the focus? Various other features
for accessibility, tablet PCs, and so on?
Very *very* annoying when using Tcl on a tablet PC. Not unlike when you
run across an app when all the usual keyboard shortcuts (ctl-A,
cut/copy/paste, etc) don't work as expected.
Synic
> Synic wrote:
>> Bryan Oakley <oak...@bardo.clearlight.com> wrote:
>>>> For me, it's not so much about features as presentation. Used amongst
>>>> the other Tile widgets, the text widget's border can look a little out
>>>> of place.
>>> Out of curiosity, did you try packing the text widget inside a
>>> ttk::entry or ttk::frame widget to get the desired look?
>>
>> I didn't try ttk::entry one as I wouldn't imagine the ttk::entry could
>> be make itself appear active and trigger its blue border highlight if
>> it's the other Tk text widget that really *is* active.
>>
>> I wouldn't think the ttk::frame widget would produce that platform native
>> antialiased rounded corner blue border when the text widget is
>> highlighted either. Same for ttk::labelframe.
>
> Instead of imagining it, spend a couple of minutes and try it. I don't
> have an aqua machine handy or I'd give it a try. On windows the outline
> looks right when I pack the text into a ttk::entry (with -padx 1 -pady
> 1), but ttk::entry widgets for me don't change appearance when they gain
> focus so I can't tell what happens when focus goes to the embedded widget.
Didn't work for me... Code used:
package require tile
grid [ttk::frame .f] -row 1 -column 1 -sticky nsew
grid [ttk::entry .f.ent1] -row 1 -column 1 -sticky nsew -padx 5 -pady 5
grid [text .f.ent2 -highlightthickness 0] -row 1 -column 1 -sticky nsew -padx 5 -pady 5
grid rowconfigure . {1} -weight 1
grid columnconfigure . {1} -weight 1
grid rowconfigure .f {1} -weight 1
grid columnconfigure .f {1} -weight 1
> I bet you can make it work by manually controlling the -state option of
> the ttk::entry widget when focus goes into the embedded text.
There's probably a binding on the ttk::entry widget's Focus which handles
that, and I guess hunting through the Tile source is the way to find what
that processes are bound to it. But that's an "another day" job.
Cheers for the suggestions.
Bryan Oakley
Well, that's not exactly what I had in mind. I suggested packing the
text widget inside an entry widget.
This actually looks pretty decent on my mac, is this the look you are after?
package require tile
ttk::entry .e1
ttk::entry .textContainer
text .t -borderwidth 0 -highlightthickness 0 \
-width 40 -height 4
bind .t <FocusIn> {.textContainer state focus}
bind .t <FocusOut> {.textContainer state {!focus}}
pack .e1 -fill x -side top -padx 4 -pady 4
pack .textContainer -fill x -side top -padx 4 -pady 4
pack .t -in .textContainer -padx 5 -pady 5
sleb...@gmail.com
Currently I can already reliably print on Windows in a native-ish way
via the Printer and GDI extensions. The GDI extension is especially
nice since it mimics the canvas. So I can easily preview my output on
canvas before sending it to the printer. I can also print on Unix in a
native-ish manner provided I have a postscript printer by simply
dumping the canvas (though, scaling the page is not as nice as the GDI
+Printer solution).
Hmm.. I've just looked at their homepage again
http://www.schwartzcomputer.com/tcl-tk/tcl-tk.html and it appears that
the license of Printer is BSD-ish, in fact more liberal than BSD. But
the license of the GDI extension is very incompatible for inclusion
with the core. In fact parts of the GDI extension has Microsoft
copyright (the author cut and pasted code from MSVC sample projects).
The big missing part right now is native CUPS printing without going
through ghostscript. All the other bits and pieces are already
available (albeit with licensing problems).
Synic
> Well, that's not exactly what I had in mind. I suggested packing the
> text widget inside an entry widget.
>
> This actually looks pretty decent on my mac, is this the look you are after?
>
> package require tile
>
> ttk::entry .e1
> ttk::entry .textContainer
> text .t -borderwidth 0 -highlightthickness 0 \
> -width 40 -height 4
> bind .t <FocusIn> {.textContainer state focus}
> bind .t <FocusOut> {.textContainer state {!focus}}
> pack .e1 -fill x -side top -padx 4 -pady 4
> pack .textContainer -fill x -side top -padx 4 -pady 4
> pack .t -in .textContainer -padx 5 -pady 5
The effect on the widget border itself looks good. But the text widget is
now limited to single-line of a limited length. Anything past "The cat sat
on the " is lost when running the above on my Mac...
To me, it looks like in getting the external border effect, it's setting
the focus to be the .textContainer entry widget rather than the .t text
widget which needs to have real focus for editing.
That's why I was saying before... I'd probably have to dig through the Tile
sources to see what's actually triggering the blue backgrounds in ttk::entry
when focus is applied, because we can't really switch focus away from the
text widget because then we can't actually use it ;-).
Synic
> The effect on the widget border itself looks good. But the text widget is
> now limited to single-line of a limited length. Anything past "The cat sat
> on the " is lost when running the above on my Mac...
Oh, wait a second...
http://pc.autons.net/stuff/interesting-bryan-effect.png
Still doesn't work, but, in a more interesting way :-)
Bryan Oakley
> Bryan Oakley <oak...@bardo.clearlight.com> wrote:
>
>>Well, that's not exactly what I had in mind. I suggested packing the
>>text widget inside an entry widget.
>>
>>This actually looks pretty decent on my mac, is this the look you are after?
>>
>>package require tile
>>
>>ttk::entry .e1
>>ttk::entry .textContainer
>>text .t -borderwidth 0 -highlightthickness 0 \
>> -width 40 -height 4
>>bind .t <FocusIn> {.textContainer state focus}
>>bind .t <FocusOut> {.textContainer state {!focus}}
>>pack .e1 -fill x -side top -padx 4 -pady 4
>>pack .textContainer -fill x -side top -padx 4 -pady 4
>>pack .t -in .textContainer -padx 5 -pady 5
>
>
> The effect on the widget border itself looks good. But the text widget is
> now limited to single-line of a limited length. Anything past "The cat sat
> on the " is lost when running the above on my Mac...
Interesting. When you type in the four-line window on the bottom you can
only enter one line of text? Strange. On my mac it works exactly as
expected. The first entry widget is just a normal entry widget to use
for comparison.
I notice I forgot to turn -takefocus off for the underlying entry
widget, so you need to press <tab> twice when focus is in the widget at
the top. You can just click in the text widget though.
>
> To me, it looks like in getting the external border effect, it's setting
> the focus to be the .textContainer entry widget rather than the .t text
> widget which needs to have real focus for editing.
Not exactly. It's not setting focus anywhere, it's just setting the
state of the underlying entry widget to the "focus" state, which causes
its focus ring to display. The focus state is different than the actual
notion of which widget has focus.
>
> That's why I was saying before... I'd probably have to dig through the Tile
> sources to see what's actually triggering the blue backgrounds in ttk::entry
> when focus is applied,
It's the setting of the state to "focus". Tile widgets handle state a
bit differently than normal Tk.
> because we can't really switch focus away from the
> text widget because then we can't actually use it ;-).
>
It's very strange that you can't use it, because it works fine for me.
Here's a screenshot:
http://www.purl.org/net/oakley/ttkentry.gif
Oh well, it was just an experiment.
Joe English
>David Welton wrote:
>> Sometimes if you ignore things long enough, they'll go away. It seems
>> that 'REST' is what people are talking about these days, and all that
>> is is HTTP.
>
>Sounds like we're about ready for the backlash against REST. :-) To be
>a little bit serious, the problem with REST is that it's hard to
SOAP vs. REST is comparing apples and orangutans -- REST is
an abstract architectural style, while SOAP is a specific
(very large) family of concrete (and very complex) protocols.
A better comparison would be SOAP vs. a concrete RESTful
protocol like GData.
>knowing how to synthesize URLs for document fragments is non-trivial;
>there needs to be some way of marking such things up, but when that
>happens you jettison the light-weight-ness of REST. To date, these
>sorts of things have tended to be ignored by virtue of making
>interfaces to the real REST part out of custom javascript, giving
>mashups but no easy route to deeper integration.
That's probably true for many REST-style protocols, especially
the simpler ones since they tend to be informally, vaguely,
and incompletely specified. But not universally -- AtomPub and
GData are two good examples at the other end of the spectrum.
And veering back on topic, support for REST-style web services
is an area that I find lacking in Tcl. The core http package is
insufficient for a lot of things you need to do on the client
side of a REST transaction, and on the server side tcllib's
ncgi.tcl is much more awkward to use than it needs to be.
That's something I think could be improved.
--Joe English
Joe English
>
>Not to look for excuses, but do you know any (scripting) language that
>supports printing for multiple platforms as a library or out of the
>box?
That's an excellent question. Are there any languages,
toolkits, or frameworks out there with good printing support?
The main obstacle to good printer support in Tcl is that
nobody knows how to do it. If somebody, anybody, has figured
this out, then we can solve the bulk of the problem just by
stealing their design.
--Joe English
Stephan Kuhagen
> That's an excellent question. Are there any languages,
> toolkits, or frameworks out there with good printing support?
Yes: http://doc.trolltech.com/4.3/printing.html
They use native printer dialogs on all plattforms and have a really nice
device abstraction using a custom widget. You can draw and print text in a
page based manner and the print via the printer abstraction.
Regards
Stephan
Kevin Walzer
wxWidgets does. It's a C++ library, but has scripting interfaces
(wxPython is the most well-known). And it seems to provide excellent
printing support across platforms, wrapping the native API on each
platform.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Arjen Markus
I just did a few experiments with CUPS: the library - at least
superficially - is very easy to use. I wrote a small program
to find out what printers there are on the system I have
access to (one call to the CUPS library and some 20 lines
for declarations and printing) and then a small program to
print a file with default options - again one call to the CUPS
library.
In the past I had been unable to find out what printers (and
especailly what properties!) my system had, so I maintained a list in
a configuration file. But CUPS seems to provide a
lot of such information for the cost of a single call.
Of course this does not solve the basic problem: what information
do we want to print and how do we get into the right shape
(file)? But there is no need to go through hoops with lp or lpr
and their options, it seems.
Regards,
Arjen
Joe English
>Most of the things on my wishlist are GUI interface matters:
>
>* Some more of the Tk widgets going into Tile would be good. Having a
>platform native spinbox and text widget would be useful, for example.
[ More on text widgets later ]
>* A way to have a completely flat button widget in either Tk or Tile
>on Mac OS X in button bars. Specifying -relief, etc, in Tk doesn't work
>at present.
You can do this with Tile pretty easily, since the
widget appearance is so simple in this case -- it's
basically just a label (image and text).
Something like:
style layout Toolbar.TButton {
Toolbar.TButton.padding -children {
Toolbar.TButton.label
}
}
style configure Toolbar.TButton -padding {... whatever looks right ... }
(The built-in Toolbutton layout on OSX will do something
like this in a future version.)
Then in application code:
ttk::button $tb.foo -image $fooIcon -text "Foo!" -compound top
Or, to better follow this week's OSX UI guidelines, generate
multiple icons and specify state-specific variants for -image,
like "-image [list $fooIcon disabled $grayFooIcon pressed $darkFooIcon]"
>* Freshening some of the other Tile widgets on Mac. In particular,
>notebook tabs are looking increasingly unusual.
Yeah, sorry about that. Tile's aqua theme appearance is
still circa OSX 10.2; I haven't been keeping up with Apple's
continual UI overhauls very well.
On that topic: if anyone knows how to draw 10.4-style "segmented
button" controls with the Carbon API, please let me know!
The ttk::notebook implementation is _almost_ capable of drawing
10.4-style notebooks, this is the only part that's missing.
--Joe English
Joe English
>Bryan Oakley <oak...@bardo.clearlight.com> wrote:
>> Well, that's not exactly what I had in mind. I suggested packing the
>> text widget inside an entry widget.
>>
>> This actually looks pretty decent on my mac, is this the look you are after?
>>
>
>The effect on the widget border itself looks good. But the text widget is
>now limited to single-line of a limited length. Anything past "The cat sat
>on the " is lost when running the above on my Mac...
First thing I'd suggest is, instead of packing a [text] widget
inside a [ttk::entry], pack it inside a [ttk::frame] that's
configured to look like a ttk::entry: [ttk::frame $f -style TEntry].
Entry widgets don't work very well as containers -- they want to
control their own width and height for one, plus there's
a lot of other built-in behavior that you need to turn off
lest it get in the way. Frame widgets work better as containers,
since that's what they were designed for.
>To me, it looks like in getting the external border effect, it's setting
>the focus to be the .textContainer entry widget rather than the .t text
>widget which needs to have real focus for editing.
>
>That's why I was saying before... I'd probably have to dig through the Tile
>sources to see what's actually triggering the blue backgrounds in ttk::entry
>when focus is applied, because we can't really switch focus away from the
>text widget because then we can't actually use it ;-).
That's controlled by the 'focus' state bit, which in turn
is controlled by a built-in event handler. (See CoreEventProc
in generic/widget.c if you're curious about the details,
but basically: [$w state focus] gets set whenever the
widget gets the focus, [$w state !focus] whenever it
loses it. This happens automatically for all Tile
widgets.)
So one approach is to set (resp. clear) the wrapper widget's
'focus' bit whenever the text widget gets a <FocusIn> (resp.
<FocusOut>) event.
The only other thing I can think of that you need to worry about
is getting the padding / borderwidth right, since that can
change from theme to theme. But if all you need to care about
is OSX, just measure it and hardcode that value.
--Joe English
Bryan Oakley
> Synic wrote:
>> Bryan Oakley <oak...@bardo.clearlight.com> wrote:
>>> Well, that's not exactly what I had in mind. I suggested packing the
>>> text widget inside an entry widget.
>>>
>>> This actually looks pretty decent on my mac, is this the look you are after?
>>>
>>> [...]
>> The effect on the widget border itself looks good. But the text widget is
>> now limited to single-line of a limited length. Anything past "The cat sat
>> on the " is lost when running the above on my Mac...
>
> First thing I'd suggest is, instead of packing a [text] widget
> inside a [ttk::entry], pack it inside a [ttk::frame] that's
> configured to look like a ttk::entry: [ttk::frame $f -style TEntry].
Hmmm. That's an interesting suggestion. That thought never reoccurred to
me. Frankly, styles and layouts are still a bit of a mystery to me (but
then, I don't use tile on a regular basis)
>
> Entry widgets don't work very well as containers -- they want to
> control their own width and height for one, plus there's
> a lot of other built-in behavior that you need to turn off
> lest it get in the way. Frame widgets work better as containers,
> since that's what they were designed for.
>
>
>> To me, it looks like in getting the external border effect, it's setting
>> the focus to be the .textContainer entry widget rather than the .t text
>> widget which needs to have real focus for editing.
>>
>> That's why I was saying before... I'd probably have to dig through the Tile
>> sources to see what's actually triggering the blue backgrounds in ttk::entry
>> when focus is applied, because we can't really switch focus away from the
>> text widget because then we can't actually use it ;-).
As I mentioned in another post, I wasn't changing focus, I was just
changing the state of the entry widget to be "focus". As you suggest in
part of your post I cut out for brevity, I did indeed bind to <FocusIn>
and <FocusOut> in the text widget to set the focus state of the
underlying entry widget.
It seemed to work, but maybe I got lucky. I'll be the first to admit it
wasn't a particularly robust solution. I was just brainstormin' of ways
to get the visual effect the user was looking for.
Neil Madden
...
> On that topic: if anyone knows how to draw 10.4-style "segmented
> button" controls with the Carbon API, please let me know!
> The ttk::notebook implementation is _almost_ capable of drawing
> 10.4-style notebooks, this is the only part that's missing.
HIThemeDrawTab?
-- Neil
Lan
say "knowledge of what's already available and where to find it." This
forum helps, because people are always courteous when one asks. The
wiki is very helpful if I already know a name or get lucky on a query.
I get Uwe's newsletter and the c.l.t digest and scour them for things
on my wish list, but that's hit or miss.
I know that there has been extensive discussion of trying to emulate
perl's CPAN, and because I haven't followed the discussion, I'll
assume that it was thoughtful and there were practical reasons not to.
So that's my contribuition to the question. I don't know how to find
out what I don't know about.
Thanks for asking.
Larry W. Virden
I am uncertain whether a CPAN emulation would help you find what you
don't know about.
As for a repository of software, you might take a look at http://wiki.tcl.tk/teacup
. It is definitely not CPAN. It is more like the ActivePerl module
repository. However, it is at least one group's attempt at providing a
repository.
The primary reason for not developing a full CPAN emulation seems to
me to be that those who are contributing to the community are all busy
with other things.
If some of those in the community who always have looked for a way to
contribute wanted to ban together to create such a thing, they could
do so.
Cameron Laird
.
.
.
>I have done great things with Tcl in the past so it is one of the most
>complete tools that I have used. Having said that, I think the following
>could be added and/or improved:
>
>1) Increase the efficiency and flexibility of smtp and smtpd. Pehaps
>this is
>more of a tutorial type of thing.
.
.
.
>3) Tutorials or introductory use cases for many packages (soap, tile,
>etc.).
>
>Is that 3 points or just one?
Have you seen <URL: http://wiki.tcl.tk/soap >, <URL: http://wiki.tcl.tk/tile >,
and so on? That's where I go to find introductory use cases ... Are you not
aware of these, or you are aware, and you don't find them adequate?
Your comment about smtp{,d} surprises me a bit. Please say a bit more; I
don't know, for example, in what sense you intend "efficiency and
flexibility". I'm fairly confident that, in the broad scheme of things,
there are several deficiencies--printing, Tk styling, UDP (!), ...--whose
rectification would have a bigger immediate impact on Tcl's usage than any
fix-ups to smtpd. My general impression is that few developers are on the
hunt for more programmability in their MTAs. What specifics do you have in
mind?
I ask this as someone who, several years ago, probably was doing as much
with Tcl and SMTP as anyone in the world. You've got me wondering what I'm
missing.
Darren New
> I ask this as someone who, several years ago, probably was doing as much
> with Tcl and SMTP as anyone in the world.
Really? Cool. Me too, a few years before that. What were you working on?
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
tom.r...@gmail.com
> SOAP vs. REST is comparing apples and orangutans -- REST is
> an abstract architectural style, while SOAP is a specific
> (very large) family of concrete (and very complex) protocols.
> A better comparison would be SOAP vs. a concrete RESTful
> protocol like GData.
> And veering back on topic, support for REST-style web services
> is an area that I find lacking in Tcl.
Yes, REST appears to be HTTP/GET with an XML-like payload in return.
I'm not really sure myself what the benefit of this scheme is. XML
still has to be handled on both ends client/server. And the point of
REST is that things don't change on the server, at least not as a
result of the RESTful operation. If this characterization is correct,
and that is a big IF, it doesn't have much in common with SOAP,
although you might be able to describe the RESTful service as SOAP/
HTTP/GET, without all the additional overhead of SOAP.
For simple, read-only services, SOAP is probably too much, and it also
lacks a useful, transferable URL for the remote object. Said another
way, the SOAP engine on the server has to reconstruct the full path of
the object as an internal process, using a combination of URL, HTTP/
SOAP headers and POST payload, maybe including SOAP-HEAD headers,
proxies, and on and on. Obviously this is not something you can
bookmark, or even successfully program. REST boils all this down into
a simple URL, which could also be constructed by the server, to
represent the product of any SOAP request. Remembering that the
request should not have any effects on the server. I'm also not sure
if a RESTful service can specialize the result based upon the identity
of the requesting client.
So I'm wondering what is missing in Tcl, as an abstract concept there
is no problem, Tcl is a programming language, supports network client/
server operations, etc. Maybe a client API for handling a particular
protocol like GData? Are there any client/server examples/APIs from
other programming languages?
But it seems important to remember that modern web services are
intended to abstract out the programming environment, which should be
a big benefit for Tcl. Yes we are probably stuck with XML, but that is
far better than dealing with encoding/decoding every possible data
structure from every programming language exposed as SOAP-RPC.
Darren New
> Yes, REST appears to be HTTP/GET with an XML-like payload in return.
Actually, REST is supposed to have URLs in the payload pointing to other
resources. The benefit is that proxies, caches, and so on can determine
not to fetch new data if you GET the same thing twice in quick succession.
> I'm not really sure myself what the benefit of this scheme is. XML
> still has to be handled on both ends client/server.
That's not fundamental to REST. That's just how people deliver the data.
> And the point of
> REST is that things don't change on the server, at least not as a
> result of the RESTful operation.
It doesn't change the server to issue a RESTful GET operation. A PUT,
POST, or DELETE will change the server.
> For simple, read-only services, SOAP is probably too much, and it also
> lacks a useful, transferable URL for the remote object.
That's what REST provides, yes.
> Remembering that the request should not have any effects on the server.
Incorrect. It's just that in the HTTP headers, where proxies and buffers
can see them, REST indicates whether the result can be buffered.
> I'm also not sure
> if a RESTful service can specialize the result based upon the identity
> of the requesting client.
Yes. Plus, you can use all the normal HTTP security stuff like SSL,
DIGEST-MD5, and so on. Unfortunately, it seems every REST service uses
their own authentication method, for some reason, rather than sticking
with the standards. (At least, most do some variation of HMAC, but pick
different things to HMAC and different places to put the result in.)
> So I'm wondering what is missing in Tcl,
Not a whole lot, really. I did a whole library to interface Tcl with
Amazon S3. It wasn't really that hard, except for the XML libraries not
really being fully functional with the 8.5a stuff at the time I was
doing that. That, and the fact that the http library invokes the event
loop even if you tell it to block, so I couldn't use that and also have
a blocking version.
I'm planning to release it to TclLib when 8.5 hits beta and I know the
syntax isn't going to change any more.
> But it seems important to remember that modern web services are
> intended to abstract out the programming environment, which should be
> a big benefit for Tcl. Yes we are probably stuck with XML, but that is
> far better than dealing with encoding/decoding every possible data
> structure from every programming language exposed as SOAP-RPC.
The main difference between REST and SOAP is that every REST interface
has to be coded from scratch in each language you want to use it from.
SOAP provides not only the wire format, but data structures for
describing the wire format at a sufficient detail that software can
generate the interface automatically for you. This also means that if
you *don't* have that automation, SOAP is a royal PITA to use, which is
why I interfaced to the AWS REST interface instead of the SOAP interface.
minu...@hotmail.fr
Cameron Laird
Darren New <dn...@san.rr.com> wrote:
>Cameron Laird wrote:
>> I ask this as someone who, several years ago, probably was doing as much
>> with Tcl and SMTP as anyone in the world.
>
>Really? Cool. Me too, a few years before that. What were you working on?
.
.
Mixed bag: Web-forum-to-mailing-list gateways (approximately);
MTA and MUA testing; and others-I'm-probably-not-remembering-now.
My summary would be: Tcl's great, as usual, but for most userland
applications in 2007, there probably are slicker ways to do the
SMTP or SMTPD functions questioners think they want.
tom.r...@gmail.com
Thanks for responding, it seems I have had a limited view of how broad
RESTful applications can be. Apparently you can use POST/PUT/DELETE.
I'm not sure how that works.
On Aug 23, 9:05 am, Darren New <d...@san.rr.com> wrote:
> tom.rmad...@gmail.com wrote:
> > Yes, REST appears to be HTTP/GET with an XML-like payload in return.
>
> Actually, REST is supposed to have URLs in the payload pointing to other
> resources. The benefit is that proxies, caches, and so on can determine
> not to fetch new data if you GET the same thing twice in quick succession.
>
Does this mean the server response should contain URLs, or a HTTP/POST
is used by the client, or can the client send a GET with payload?
> > I'm not really sure myself what the benefit of this scheme is. XML
> > still has to be handled on both ends client/server.
>
> That's not fundamental to REST. That's just how people deliver the data.
>
Hmm, I'm guessing it doesn't matter how you deliver data, XML has
severe limitations and you have to jump through a bunch of hoops to
handle binary data or binary resources. Having just spent the last few
years working with WSDL and XML-Schema, being able to describe the
service is more important. The problem is that the more you do in
SOAP, the more difficult things get for everyone. If you could get the
description of WSDL, with a more RESTful interface, that would be
nice.
> The main difference between REST and SOAP is that every REST interface
> has to be coded from scratch in each language you want to use it from.
> SOAP provides not only the wire format, but data structures for
> describing the wire format at a sufficient detail that software can
> generate the interface automatically for you. This also means that if
> you *don't* have that automation, SOAP is a royal PITA to use, which is
> why I interfaced to the AWS REST interface instead of the SOAP interface.
SOAP without WSDL is bound to suck. WSDL without WS-I Basic Profile is
still too ambiguous. The best that can be done is to choose a useful
subset of WS-I Basic, or some other limited interface which has low
ambiguity. Most web service protocols try to do way too much (too many
ways to do the same thing) for no gain in functionality. Then, and
only then, can you expect to get an automatically generated interface,
maybe even an entire application.
Donal K. Fellows
> a good book - or more - related to tcl/tk 8.5
There's one in the works (it's about 99% written to tell the truth)
but it won't be coming out until after 8.5 at least goes beta.
Donal.
Donal K. Fellows
> I'm also not sure
> if a RESTful service can specialize the result based upon the identity
> of the requesting client.
Yes it can, though typically that will just be along the lines of "yes
you can see the resource or no you can't" type specialization. It's
easier to give different people different resources (after all, a UUID
is fairly cheap). The other thing that RESTful services can do is
deliver different views of the resource depending on what your client
software negotiates with it; not that I'm in any way convinced that
this is a good idea though.
Bah, SOAP is too baroque (unless you're doing something exceptionally
complex) and REST is too naïve (too many pieces feel like hacks, and
too many people are peddling it - with webmashups2.0.net or whatever
the latest snake-oil is - as the solution to things which it doesn't
really help with). I'd much rather write Tcl scripts. :-)
Donal.
Darren New
> Apparently you can use POST/PUT/DELETE.
It's not just that you can, but that you *must*. Otherwise, it isn't
REST. (Rather, you MUST if you want the associated semantics.)
> I'm not sure how that works.
I'm not sure what you're confused about. You use them as the verb,
instead of GET.
> Does this mean the server response should contain URLs,
The original description of REST said that the result should contain
URLs. So if, for example, you have (say) a directory listing of
http://my.files.com/Darren/Videos, that should return data with a number
of URLs all presumedly like http://my.files.com/Darren/Videos/Whatever.mpeg
> or a HTTP/POST is used by the client,
If they want POST semantics, yes.
> or can the client send a GET with payload?
I don't think the spec allows for a payload with GET, but I might be wrong.
> Hmm, I'm guessing it doesn't matter how you deliver data, XML has
> severe limitations and you have to jump through a bunch of hoops to
> handle binary data or binary resources.
Right. So you deliver a textual document with URLs that point to
resources that are in turn delivered with binary content-transfer-encodings.
> Having just spent the last few
> years working with WSDL and XML-Schema, being able to describe the
> service is more important. The problem is that the more you do in
> SOAP, the more difficult things get for everyone. If you could get the
> description of WSDL, with a more RESTful interface, that would be
> nice.
Yep. Automating that stuff would be nice. Of course, that's what XML is
*supposed* to allow, but instead it's more like XML is a technology to
avoid describing your transfer interfaces.
> SOAP without WSDL is bound to suck.
Yes. I'm amazed at the number of one-cheek SOAP servers that interact
only with themselves. Why use SOAP if it only interfaces to programs
using the same library for both client and server?
And the bit of having to still rely on HTTP cookies for any sort of
inter-call context (e.g., "I did a search, and now I want the next page
of results") is just silly. Especially since SOAP is supposed to be
transport-independent.
Darren New
it takes advantages of all the technologies you wouldn't need if you
weren't using HTTP as a transport in the first place.
arlie
> On 13 aug, 17:43, "Larry W. Virden" <lvir...@gmail.com> wrote:
>
>
>
> > Over the years, I've seen many people post about how tcl should have
> > this or that to compete with this language or that framework.
>
> > That's not what this posting is about.
>
> > What this thread is about - hopefully - is identifying areas in which
> > you, as a tcl developer, have a need, but have been unsuccessful in
> > locating a solution.
>
> > Maybe it is a tool, or maybe it is an extension. Maybe it is an
> > example or a tutorial.
>
> > I hope that people feel free to post a quick note mentioning specific
> > needs that you have, and that other readers feel free to chime in with
> > suggestions for meeting those needs.
>
> > For instance, if someone were to post that they have a need for
> > calculating some specific checksum for some particular kind of data,
> > and someone else knows of a place where that kind of code might be
> > found, feel free to post the location. Or, if you don't know of a
> > place, but perhaps have created a page over athttp://wiki.tcl.tk/
> > that discusses the issue, feel free to mention that.
>
> > What I hope to see in this thread are those undiscovered gems that I
> > am certain reside out there around the net, or strategies for solving
> > the problems, along with, hopefully, some updates on the wiki to help
> > future developers.
>
> > Thanks!
>
> And to add my own 2c. What I have missed recently is http 1.1 (or at
> least http supporting keepalives) this is required for some
> authenticating proxies for instance. There are some changed versions
> of the http package which include this, but it would be nice if the
> core http supports it.
>
> Mark
realbasic