What is Borges?

[Carl Youngblood]

--------------ms070701060507010705010004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Good points. The second problem could be fixed by not storing state
information in the session. Store information in the page itself or in
the URL that determines whose record you are updating and only use the
session for checking who is logged in and what their permissions are.
The problem with limited GET size would never be a problem for me
because all I hold in the session is usually a session id (32 bytes) and
maybe a userid and username of who is logged in. All other information
I can retrieve on a per-page basis from the database. Session bloat is
IMO something that should be strictly avoided, especially because
storing something in a session is inherently unsafe. The brownie idea
is what amazon.com uses. It's actually a pretty good solution. And of
course, none of these solutions will help a user who forgets to log out.

Carl

One. Picture two students, roommates, with one computer between them.
Student "A" logs into the online registration app and registers for a
few classes, and then minimizes the browser window without logging
out. Shortly thereafter, Student "B" comes along, opens a new browser
window (not realizing that there is already a window open, but
minimized) and logs into the online registration app. He then
registers for a few classes, and closes his window (without logging
out). Student "A" returns, and restores his browser window, intending
to add a few more classes. AT THIS POINT, THE SESSION REFLECTS THE
ACTIVITY OF STUDENT B, NOT STUDENT A. When Student A adds a class, he
inadvertantly adds it to Student B's schedule, which may not actually
be realized until the semester starts. This problem actually bit us
hard a few years ago.

Two. Picture an administrative employee. They are editing a student's
grade history when they get a phone call. It is another student with a
question about their grades, so the employee (not wishing to lose
their place) opens a new window and uses it to answer the student's
question. Then, they close that new window to return to their place.
THE SESSION NOW REFLECTS THE CALLER'S IDENTITY, NOT THE ORIGINAL
STUDENT'S IDENTITY. Thus, when the employee changes a grade, it goes
to the caller's record, not the original student's! This also bit us
hard a few years ago.

We got around this by using what we have called a "brownie." It is the
encoded and encrypted session information, stored in a hidden field on
the page itself and propogated via POSTs. (Another problem with using
GET, in addition to what I've read in this thread, is that GETs are
technically limited to 1k of data, which--in our case--is often
insufficient to transmit the brownie.)

--------------ms070701060507010705010004
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPxjCC
BMgwggQxoAMCAQICBAIAApswDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNV
BAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0w
MjA4MjcxOTA3MDBaFw0wNjAyMjMyMzU5MDBaMIHcMQswCQYDVQQGEwJHQjEXMBUGA1UEChMO
Q29tb2RvIExpbWl0ZWQxHTAbBgNVBAsTFENvbW9kbyBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL
Ez1UZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9y
ZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAyIENvbW9kbyBMaW1pdGVkMSwwKgYDVQQDEyND
b21vZG8gQ2xhc3MgMyBTZWN1cml0eSBTZXJ2aWNlcyBDQTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALEeYGbgQwaeJ2gvApnHiN+F69tl7NRJZ3ouH83cFSzWHqzynUY6XQPA
PQUsWhgNWSVCo3LArSjSrTwx4ksH+16Y66gz1mmyWp7qLEmmJi5M8MyrQNKq3ixOgbW6e7hc
0Hu9R/XABtLA5NdH22JAr6EcUQMY27jQu5THPHnqJWSuJhnhPGZHZ5Kde1WrNMJ1btknjp2M
8B3aa5yGBKKQteqdjM/7OUOo8BgtnvcZECycL+HQsf/XWcTNQDL514HbURzyQVKBQbGDuMgJ
/pkiR4BPnMuu4CjVHKxwR7Alq6E4Qhdr+mpujV95+PYpAzCkbkbUhV2qQJk4dtseAX3lDKUC
AwEAAaOCAacwggGjMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGljLXRydXN0
LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFPZSIhcVEwgDWb8YlZ9I
tLnp/vhmMIGSBgNVHSAEgYowgYcwSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1odHRw
Oi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwOgYMKwYBBAGyMQEC
AQMBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1AwWAYDVR0j
BFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoG
A1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMjA4MjcxOTA3
MzFagQ8yMDA1MDIyMzIzNTkwMFowDgYDVR0PAQH/BAQDAgHmMA8GA1UdEwQIMAYBAf8CAQAw
DQYJKoZIhvcNAQEFBQADgYEAtqewenGL4LqzgR42MnqGGNbxq005CHEGWmegSwHlMEBtibWe
Faqxx/QKxlwO6TfeqJfH3M7Ncft0AgfcXxUnCFMHdtS5BunCd1AeysmwwkaBgACtRKpc1iDZ
VTK+Vpbx6r2g47wNgDrqzPuaV+14pTY9VurR53TKNMPPsVHp4AwwggV5MIIEYaADAgECAhEA
0778lNvXcqTJcbJWukDeKDANBgkqhkiG9w0BAQUFADCB3DELMAkGA1UEBhMCR0IxFzAVBgNV
BAoTDkNvbW9kbyBMaW1pdGVkMR0wGwYDVQQLExRDb21vZG8gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u
ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMiBDb21vZG8gTGltaXRlZDEsMCoGA1UE
AxMjQ29tb2RvIENsYXNzIDMgU2VjdXJpdHkgU2VydmljZXMgQ0EwHhcNMDMwNzA2MDAwMDAw
WhcNMDQwNzA1MjM1OTU5WjCB3zE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ
RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m
IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw
MDMgQ29tb2RvIExpbWl0ZWQxGDAWBgNVBAMTD0NhcmwgWW91bmdibG9vZDEjMCEGCSqGSIb3
DQEJARYUY2FybEB5b3VuZ2Jsb29kcy5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
AKtIZSyfoppNIZm8EwguRgIMPh8Sohgro0UwKanm8DXCPiLWFd25/2WjoCB0VYUMXVEC7D+c
tvpruXiLH9lKuD2WNvdHUzr2EdyBP7uJ7Q7C4lMpIjQRtYCOeSH3CeZcy6FyLKZ8jOtV/BgH
fWsaX/z8u29bktnr1K18MCNIKq7RAgMBAAGjggGzMIIBrzAfBgNVHSMEGDAWgBT2UiIXFRMI
A1m/GJWfSLS56f74ZjAdBgNVHQ4EFgQUrG/w0IpUWEnwYe5gDksKWgjVwqcwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC
MEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj
dXJlLmNvbW9kby5uZXQvQ1BTMIGwBgNVHR8EgagwgaUwOKA2oDSGMmh0dHA6Ly9jcmwuY29t
b2RvLm5ldC9DbGFzczNTZWN1cml0eVNlcnZpY2VzXzIuY3JsMDqgOKA2hjRodHRwOi8vY3Js
LmNvbW9kb2NhLmNvbS9DbGFzczNTZWN1cml0eVNlcnZpY2VzXzIuY3JsMC2gK6ApgSdDbGFz
czNTZWN1cml0eVNlcnZpY2VzXzJAY3JsLmNvbW9kby5uZXQwEQYJYIZIAYb4QgEBBAQDAgUg
MB8GA1UdEQQYMBaBFGNhcmxAeW91bmdibG9vZHMub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAR
powtW8sldyqXAfqn276jiYMlTBSX6BH1pjnIHNiYECywMi1txd8hRB3c/iHXCyAHuYq3AgRI
WegFJ+8/B1jGcUxDjvzmSSjnhFSztT1oNJZUrw0yYhdp+yWDjov24sKFFWYwC4rsnO0y6y9D
U9qAyrKk7NuwHp/NPR2tujpnvStgFLk3hvJTUj3Cu//+OXuqPwk6pIDYvnsGkISIkYfO8kQz
F39TAlNLkyBIsrzZdTotnSNlkwgzW1Ys62MRjZsC6zlrv2dMPxn0iyrxxtse3d82EF1Y53B/
hWvgGoQfQtnsz9bJSPbl9CvfMqPO/fRxGomUcOCSr7NPdoafve+JMIIFeTCCBGGgAwIBAgIR
ANO+/JTb13KkyXGyVrpA3igwDQYJKoZIhvcNAQEFBQAwgdwxCzAJBgNVBAYTAkdCMRcwFQYD
VQQKEw5Db21vZG8gTGltaXRlZDEdMBsGA1UECxMUQ29tb2RvIFRydXN0IE5ldHdvcmsxRjBE
BgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5jb21vZG8u
bmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDIgQ29tb2RvIExpbWl0ZWQxLDAqBgNV
BAMTI0NvbW9kbyBDbGFzcyAzIFNlY3VyaXR5IFNlcnZpY2VzIENBMB4XDTAzMDcwNjAwMDAw
MFoXDTA0MDcwNTIzNTk1OVowgd8xNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0g
UEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv
ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYyky
MDAzIENvbW9kbyBMaW1pdGVkMRgwFgYDVQQDEw9DYXJsIFlvdW5nYmxvb2QxIzAhBgkqhkiG
9w0BCQEWFGNhcmxAeW91bmdibG9vZHMub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCrSGUsn6KaTSGZvBMILkYCDD4fEqIYK6NFMCmp5vA1wj4i1hXduf9lo6AgdFWFDF1RAuw/
nLb6a7l4ix/ZSrg9ljb3R1M69hHcgT+7ie0OwuJTKSI0EbWAjnkh9wnmXMuhciymfIzrVfwY
B31rGl/8/LtvW5LZ69StfDAjSCqu0QIDAQABo4IBszCCAa8wHwYDVR0jBBgwFoAU9lIiFxUT
CANZvxiVn0i0uen++GYwHQYDVR0OBBYEFKxv8NCKVFhJ8GHuYA5LCloI1cKnMA4GA1UdDwEB
/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF
AjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3Nl
Y3VyZS5jb21vZG8ubmV0L0NQUzCBsAYDVR0fBIGoMIGlMDigNqA0hjJodHRwOi8vY3JsLmNv
bW9kby5uZXQvQ2xhc3MzU2VjdXJpdHlTZXJ2aWNlc18yLmNybDA6oDigNoY0aHR0cDovL2Ny
bC5jb21vZG9jYS5jb20vQ2xhc3MzU2VjdXJpdHlTZXJ2aWNlc18yLmNybDAtoCugKYEnQ2xh
c3MzU2VjdXJpdHlTZXJ2aWNlc18yQGNybC5jb21vZG8ubmV0MBEGCWCGSAGG+EIBAQQEAwIF
IDAfBgNVHREEGDAWgRRjYXJsQHlvdW5nYmxvb2RzLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEA
EaaMLVvLJXcqlwH6p9u+o4mDJUwUl+gR9aY5yBzYmBAssDItbcXfIUQd3P4h1wsgB7mKtwIE
SFnoBSfvPwdYxnFMQ4785kko54RUs7U9aDSWVK8NMmIXafslg46L9uLChRVmMAuK7JztMusv
Q1PagMqypOzbsB6fzT0drbo6Z70rYBS5N4byU1I9wrv//jl7qj8JOqSA2L57BpCEiJGHzvJE
Mxd/UwJTS5MgSLK82XU6LZ0jZZMIM1tWLOtjEY2bAus5a79nTD8Z9Isq8cbbHt3fNhBdWOdw
f4Vr4BqEH0LZ7M/WyUj25fQr3zKjzv30cRqJlHDgkq+zT3aGn73viTGCBF4wggRaAgEBMIHy
MIHcMQswCQYDVQQGEwJHQjEXMBUGA1UEChMOQ29tb2RvIExpbWl0ZWQxHTAbBgNVBAsTFENv
bW9kbyBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiB1
c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAy
IENvbW9kbyBMaW1pdGVkMSwwKgYDVQQDEyNDb21vZG8gQ2xhc3MgMyBTZWN1cml0eSBTZXJ2
aWNlcyBDQQIRANO+/JTb13KkyXGyVrpA3igwCQYFKw4DAhoFAKCCAsEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNTA4MDM1MzQ0WjAjBgkqhkiG9w0B
CQQxFgQUe42uSYSkLfS2ksnVnJo/Z6cbK/cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwggEDBgkrBgEEAYI3EAQxgfUwgfIwgdwxCzAJBgNVBAYTAkdCMRcwFQYDVQQKEw5Db21v
ZG8gTGltaXRlZDEdMBsGA1UECxMUQ29tb2RvIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPVRl
cm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9z
aXRvcnkxHzAdBgNVBAsTFihjKTIwMDIgQ29tb2RvIExpbWl0ZWQxLDAqBgNVBAMTI0NvbW9k
byBDbGFzcyAzIFNlY3VyaXR5IFNlcnZpY2VzIENBAhEA0778lNvXcqTJcbJWukDeKDCCAQUG
CyqGSIb3DQEJEAILMYH1oIHyMIHcMQswCQYDVQQGEwJHQjEXMBUGA1UEChMOQ29tb2RvIExp
bWl0ZWQxHTAbBgNVBAsTFENvbW9kbyBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz1UZXJtcyBh
bmQgQ29uZGl0aW9ucyBvZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5
MR8wHQYDVQQLExYoYykyMDAyIENvbW9kbyBMaW1pdGVkMSwwKgYDVQQDEyNDb21vZG8gQ2xh
c3MgMyBTZWN1cml0eSBTZXJ2aWNlcyBDQQIRANO+/JTb13KkyXGyVrpA3igwDQYJKoZIhvcN
AQEBBQAEgYBg+FG3kDSAXRkBTwFPSjPDFgprW2Cf6flDWHhfpHwmsCSvhiLkNR1P8Gs9pAOR
MCvZvgoCTe5Xtw0/pZPrvTpkRsCsXFQtNWCKtxcXUXSuS7+JLngDfkJvgPznL5Yq9eFUdDO3
KrYPlDN1adH1fDPbHLjzxQEux+NWiWUIcYCf2wAAAAAAAA==
--------------ms070701060507010705010004--

 

[Francis Hwang]

Seaside/Borges use GET parameters for session. Avi and I do not like
using cookies for session keys, not just because of the obvious problem
that some people disable cookies but also because it prevents the user
from having two windows open in two different sessions at the same time.

It wouldn't be hard at all to support cookie-based session keys
instead--just a simple matter of programming--but we have no desire to
have such a feature. We have had clients express interest, though, so
if it was something that somebody really wanted, we would probably
consider adding it (to seaside, that is).

What does a session imply here? Is there any room in this paradigm for
reflecting some state in a cookie and some state in a URL?

Let's say I'm selling some of my old CDs online, using a site that
uses cookies for login. And I want to reprice them by opening up a
bunch of tabs in my browser, which all might point to URLs like

http://my.site.com/reprice.rb?item=8787
http://my.site.com/reprice.rb?item=8788
http://my.site.com/reprice.rb?item=8789
http://my.site.com/reprice.rb?item=8790

There are two types of state here: The logic information keyed to a
cookie, and the item information keyed in the URL. Is this the sort of
thing that could be done in Borges?

From seeing the presentation at RubyConf last year it seemed very
impressive to me, but at the same time I had reservations because it
seemed like URLs that are so dependent on state would heavily resist
bookmarking ... are those reservations fair?

Francis

 

[daz]

Have a look at www.csszengarden.com for inspiration if you haven't yet
discovered the power of CSS.

Cheers,

Julian

<gasp>
Thank you,

http://www.meyerweb.com/eric/css/edge/


daz

 

[Julian Fitzell]

That is what I have seen usually done.

Borges doesn't use meaningful values for parameters in URLs. All the
GET/POST parameters are unique keys which tell the system which link to
click on, etc. Every link, every button, and every form field has an
associated callback block which, in the case of a button or link is
executed or in the case of a field is passed the new value for the
field. You never need to think about marshalling the state out as a
string in the URL. If you iterate over a list of objects and print out
an anchor for each, the object will get captured in the context of the
callback block and you'll have it to work with when the block is executed.

But see below...

Bookmarking is an issue with Seaside/Borges just as it would be with,
say, Microsoft Word. But again, it just comes down to defining your
desired semantics. What does it mean if I create a bookmark while in
the find and replace dialog with foo.doc open and "bar" typed in the
find field?

If I go back to that bookmark do I expect to be in the same place? with
the same file open? with the field filled in? What does the user
expect a bookmark to be when they're in the middle of buying the items
in their Amazon cart?

That's what I've been told. Supposedly Borges is for application
development so users shouldn't be bookmarking URLs, since they reflect a
particular state of the program and not a place where content is

It's not that the user *shouldn't* be bookmarking. It's just that the
semantics aren't necessarily clear. But you're right that
Seaside/Borges are primarily designed for web /application/ development.
It makes many of the problems like complex session state and program
flow simple but the tradeoffs may not be worth it for all projects.
Pick the right tool for each job...

located. I disagree with this compartmentalization, since I can
envision plenty of content-based web sites that use authentication.

I'm not sure I understand the significance you attribute to
authentication here.

The way Seaside handles bookmarking in general (not sure if Borges
implements this) is that you can add URL segments for your own use. So,
by default it might generate a URL that looks like:

/seaside/myapp/@fovoYawazbbotlBU/CvKjJaGf

but you can, based on the section you're currently in, ask it to make a
URL like this instead:

/seaside/myapp/browse/8789/@fovoYawazbbotlBU/CvKjJaGf

If the session key and page key can be found, the user will go back to
exactly the same place in their session. If they cannot, you are given
a chance to select a default entry point. You can then use
/browse/8789/ to figure out that they were on a browse page looking at
item 8789.

It just comes down to figuring out the semantics you want (same as with
the back button). Heck, if you have enough disk space, you can write
all the sessions out to disk so if the user ever comes back with a
bookmark, they'll actually end up exactly where they left off. Let's
see Word try that...

Julian

 

[Kirk Haines]

On Sat, 8 May 2004 13:03:56 +0900, Francis Hwang wrote

What does a session imply here? Is there any room in this paradigm
for reflecting some state in a cookie and some state in a URL?

A session is all of the data that makes up a user's unique interaction with
the application.

With Iowa one can use the query string portion of a URL, if one wants.
However, in my own use I've never found the need to put data back into a
query string. It's simply used as an entry point to provide parameters.

Example: I have an application that provides a report on roof conditions
for buildings. This application takes a set of query string parameters that
provide information on what data to query for the report. The report,
however, is interactive, so once they click on a control to start changing
what is being displayed in the report, the query string parameters are left
behind and everything is kept on the server associated with the session.

Let's say I'm selling some of my old CDs online, using a site that
uses cookies for login. And I want to reprice them by opening up a
bunch of tabs in my browser, which all might point to URLs like

http://my.site.com/reprice.rb?item=8787
http://my.site.com/reprice.rb?item=8788
http://my.site.com/reprice.rb?item=8789
http://my.site.com/reprice.rb?item=8790

There are two types of state here: The logic information keyed to a
cookie, and the item information keyed in the URL. Is this the sort
of thing that could be done in Borges?

Not exactly the way that you show. *ponder* Hmm, Eric, how would you do
this with Borges?

With Iowa, if one expected that someone would want to do this, then one
could create an entry point into the application mapping /reprice to the
Reprice component, for example. And the Reprice component would look for an
item= parameter to get the item number. This would let the application
construct URLs like this:

http://my.site.com/reprice?item=8787
http://my.site.com/reprice?item=8788

and so on.


Kirk Haines

 

[Kirk Haines]

On Sat, 8 May 2004 13:19:37 +0900, Carl Youngblood wrote

That's what I've been told. Supposedly Borges is for application
development so users shouldn't be bookmarking URLs, since they
reflect a particular state of the program and not a place where
content is located. I disagree with this compartmentalization,
since I can envision plenty of content-based web sites that use
authentication. Please correct me if I'm wrong here, Borges people.

If you have an application that a mutual fund company uses to enter
performance information about their funds for their web site, creating a
bookmark in the middle of that application isn't going to be useful as the
content at that time is inherently transitional. The user is in the middle
of doing something, and when that something is done, that prior state is no
longer relevant. So, one can bookmark the entry point into the application,
but bookmarks while working in the application are going to be ugly URLs
that are only relevant for a limited period of time. This is the kind of
application that the Borges model works well for.

The places where the model gets difficult are for sites that have sections
that are application-like, but have other areas that are not. A job search
site, for example, fits this. You have several areas that are small
applications in a job search site, from entering information to searching
it. while holding onto some session data such as your login id. However,
when you find a piece of information that is of interest, you want to be
able to bookmark it and be able to come back to the same piece of data an
hour, a day, or a week later.

If you want to do the whole site in Borges, instead of choosing to write
just the inherently transitional application areas like the data entry areas
in Borges, and the other end-data areas in something else, it may be
difficult (though, I think, possible, if someone really wanted to do it).

At one point I ran into this very problem with Iowa at one point. I was
taking over a large site that had been implemented in ASP. I, however, was
getting none of the ASP that actually implemented the site, and one of the
site's features is that most of its URLs have 2 different pieces of content,
depending on whether one is logged into the site or not (and a login gets
tracked with a cookie). Additionally, there are areas interspersed through
the site where one gets into application-like interfaces, with data entry or
with pages getting a lot of data from a database. So I needed to be able to
do a whole site dynamically in the sense that login information has to be
checked for every page load, and one of two content pieces delivered
depending on that login information. Additionally, in some cases those
content pieces had to themselves be dynamic and application-like. And
nearly every URL has to be a clean looking, bookmarkable URL.

I looked at 6 or 7 different ways of doing this, but I really wanted to be
able to implement the entire site under the same framework for simplicity's
sake, and I really liked how easy it was to build dynamic content displays
under Iowa. In the end I built a relatively simple mapping layer to map
URLs to specific components. Voila! All the ease and simplicity of Iowa
templating and dynamic content generation; I could do the whole site under
it, using its features where I needed them and just using plain HTML files
for the static content areas where I didn't.

Ah, baby is crying, so I'll quit rambing and go soothe a little girl, now.


Kirk Haines

 

[Kaspar Schiess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carl Youngblood wrote:

| That's what I've been told. Supposedly Borges is for application
| development so users shouldn't be bookmarking URLs, since they reflect a
| particular state of the program and not a place where content is
| located. I disagree with this compartmentalization, since I can
| envision plenty of content-based web sites that use authentication.
| Please correct me if I'm wrong here, Borges people.

There are two kinds of state information in Borges, as in every other
web application:
a) Stuff that is page view related
b) Stuff that is session releated

And of course there is a third category that needs to stick around like
my login at rubyforge for example (if I choose it to stick around).

The two points a) and b) can easily be done in Borges in a scope that is
limited by a session timeout (600 secs default). After that, things get
cleared and user restarts from scratch, *unless* of course the
application saves off some state to a database, like my basket's
contents. Or saves it off to the users computer, like my login cookie.

Limited support for path handling is also provided, meaning that if my
application lives at /borges/app, I can provide bookmark links to
/borges/app/user/manager and have new sessions to that path directly
start at the right point in application. Using this feature, I can even
deal out a bookmark to /borges/app/user/manager@SESSIONID to my friends.
This will prompt a new session if SESSIONID is old, or reuse the old
session, *unless* the old session depends on a cookie for authorization
of course.

So everything that always was there can be done with Borges, it's just
that it makes handling of short time application state a lot easier with
the added bonus of being able to fork&backtrack user threads (not in an
os kind of meaning here).

The bookmarking of application state is encouraged on a short time
scale, and can be made possible on a long time scale.

Now to the question where you would use Borges, I think that your
average display of dynamic lists from a database is not where Borges is
best. (For example shops, search over a big database with result
browsing, etc..) Borges is very good at neatly describing complex
interaction tasks: Everything that goes in the direction of one window
on top of that other one, closing it and reopening another one.. in
short the more complex application like web interactions that are a pain
to bring to life with traditional request/response web systems.

It probably is wise to mix Borges in on systems partly built with
traditional paradigms.

These are extremely complex issues to explain when trying to describe it
~ based on the vocabulary that is in use on the web right now. I would
encourage you all to make a short investigation, running the tests and
considering the implications.


- --
kaspar

semantics & semiotics
code manufacture

www.tua.ch/ruby
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAnNhgFifl4CA0ImQRAiJIAJ9cHTzagAhCFN1ibYXGRpaziopEtQCfdFaK
M4iQiJL2RxXqVyv/6qrU3zY=
=OQGf
-----END PGP SIGNATURE-----

 

[Carl Youngblood]

Re: [OT] CSS (was Re: What is Borges?)

 

[Chad Fowler]

So far, Borges is on par with Seaside 2.3 for the purposes of evaluating
innovation.

Just to clarify Eric, what do you mean by this exactly? Do you mean
that Borges has innovated as much as Seaside has or that Borges is
essentially the same as Seaside, so the innovations from Seaside have
been included?

The SVG stuff sounds pretty neat. I didn't realize that Borges had an
active mailing list. I'll add that to my too-long list of
subscriptions.

Thanks,
Chad

 

[Julian Fitzell]

Just as a further piece of information, the Borges you're all talking
about (for Ruby) is a port of Borges for Smalltalk. Borges is what we
called the new kernel of Seaside 2.x while it was in development. The
name never really stuck though and we mostly just refer to Seaside2 now,
but if you read the quote at http://www.beta4.com/seaside2/ you'll see
where the name Borges comes from.

The Borges kernel docs are at http://beta4.com/seaside2/borges.html in
case anyone is interested in taking a look. It's pretty low-level (not
designed for end-users) and isn't at all up-to-date for the 2.5.x series
that is currently in alpha.

Cheers,

Julian