Menu
▾
▴
confab-developers — Context Fabric Developer's Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(1) |
|---|
|
From: Jason I. H. <ja...@cs...> - 2002-12-01 08:11:47
|
Hey all,
I've been hacking away this weekend, made decent progress.
Here are some changes:
- added sorting capabilities to queries (see bottom of
this message)
- removed some methods from InfoSpaceAccess (basically the
redundant ones). The API is more like a tuple space now,
consisting of:
- addDocument
- removeDocument
- getDocument
- query
- subscribe
- unsubscribe
If it's ok, I'd like to rename the methods, getting rid
of the word "document". Let me know what you think.
- added in, on, and out operator functionality for InfoSpaces
in-operators modify incoming data before the InfoSpace sees it
out-operators modify outgoing data before it flows out
on-operators run periodically (ex. garbage collection)
The idea here is to make it simpler to add new orthogonal
functionality. For example, some out-operators would be filter,
blur, and add-privacy-tags.
(There is a potential bug here since Liquid gets the tuples
as they flow in, meaning that they can flow out without going
thru the out-operators)
- added transaction IDs to data as it flows out
(you'll notice that ContextTuples now have these IDs in them,
which will be used for logging purposes too, to make it a little
easier to understand what data flowed out)
- added simple UDP support for HTTPU notifications
(This almost works, I'm going to take another whack at it to
fix some architectural ugliness)
------
So here's an example request that you can make in URL form:
http://localhost:8080/infospace/jasonh?
q=//ContextTuple[@datatype='location.room']
&sortby=//ContextTuple/@timestamp-created
&sortorder=descending
&num=2
This says:
- Go to Jason's infospace
- Get all data with datatype='location.room'
- Sort by the timestamp created
- Sort descending
- Maximum tuples returned is 2
The parameters are specified in the mapParams variable
in InfoSpaceAccess. The constants used to define these
are defined in Confab.java.
--
Jason I. Hong | Group for User Interface Research
ja...@cs... | University of California, Berkeley
http://www.cs.berkeley.edu/~jasonh | http://guir.cs.berkeley.edu
|
|
From: Jason H. <ja...@cs...> - 2002-11-22 00:27:55
|
FYI, I added a new class called ContextTupleTypes that takes an attribute name and returns whether it is a String, Integer, Double, or Date. It just has a static lookup map. |
|
From: Jason H. <ja...@cs...> - 2002-11-21 02:21:07
|
One extra comment. Something to consider is, is this schema something that only has to be defined once for all time (which I'm thinking it is)? If so, then whatever eventual option might not be too bad. I think the worst choice is to have something that app developers would have to muck around with. A stopgap measure would be something like: - I want to sort on attribute "dateformat" - It goes to a lookup table and sees that "dateformat" is of type "date" - It pulls the "date" sorter and then does the right thing If we use this abstraction, then we can hide the details of whatever schema definition we use in the lookup table. Does this sound feasible for what we want and reasonable? ----- Original Message ----- From: "Jeffrey Heer" <jh...@cs...> Date: Wednesday, November 20, 2002 6:09 pm Subject: [Confab-developers] RE: XML Schemas and Confab types > This approach is fine with me for now, but I need to think some > more on > what consequences it may have down the road. But then by the time > we'redown the road a better solution may have presented itself. > |
|
From: Jeffrey H. <jh...@cs...> - 2002-11-21 02:10:48
|
This approach is fine with me for now, but I need to think some more on what consequences it may have down the road. But then by the time we're down the road a better solution may have presented itself. I'm just wrapping up Condition classes (package confab.doc.condition) that will evaluate simple predicates on collections of ContextTuples. They use a very generic access procedure (that has yet to be implemented, though I added a stub to ContextTuple. Any takers? Jason?) to pull Strings out of the tuples and then try to parse the String as the proper type given the kind of comparison that is required. In short, it assumes the code authors knew what they were doing and throws an exception if it discovers otherwise. Alan, let us know if these approaches pose any problems for you as you translate from queries to query plans. Jeff -----Original Message----- From: con...@li... [mailto:con...@li...] On Behalf Of Jason Hong Sent: Wednesday, November 20, 2002 5:57 PM To: con...@li... Subject: [Confab-developers] XML Schemas and Confab types After perusing thru XML Schemas for a while yesterday and today, I think I'm ready to recommend that the Pope add it to the Index of banned books. Basically, it suffers the same problem a lot of XML does, which is that it mixes the easy and the hard together, making it pretty difficult to understand. So here's my current opinion on types, which is that we should just use "well-known" attributes and tags that have well-known types. So for example, attribute "dateformat" is always type date, "confidence" is always type int, and so on. One way to manage this in the long run is to have a lib that helps do this for us, instead of sprinkling parsing and all thru the code. Thoughts? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Confab-developers mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/confab-developers |
|
From: Jason H. <ja...@cs...> - 2002-11-21 01:57:47
|
After perusing thru XML Schemas for a while yesterday and today, I think I'm ready to recommend that the Pope add it to the Index of banned books. Basically, it suffers the same problem a lot of XML does, which is that it mixes the easy and the hard together, making it pretty difficult to understand. So here's my current opinion on types, which is that we should just use "well-known" attributes and tags that have well-known types. So for example, attribute "dateformat" is always type date, "confidence" is always type int, and so on. One way to manage this in the long run is to have a lib that helps do this for us, instead of sprinkling parsing and all thru the code. Thoughts? |
|
From: Jason I. H. <ja...@cs...> - 2002-11-18 01:33:35
|
Hey All, Just FYI, don't forget to periodically delete classes/*.class files, because ant doesn't do Java dependency checks, it just looks at the date of files. Right now, some of the files in query aren't building because I removed ContextDocument (replaced it with ContextTuple). -- Jason I. Hong | Group for User Interface Research ja...@cs... | University of California, Berkeley http://www.cs.berkeley.edu/~jasonh | http://guir.cs.berkeley.edu |
|
From: Jason H. <ja...@cs...> - 2002-11-14 03:27:41
|
- Rewrote how context documents are represented, from ContextDocument to ContextTuple. - Changed the result of InfoSpaceAccess queries, so now you get a List of ContextTuples. - Added logging, so that each infospace has its own log file. - Added more error messages, which get propogated through to the HTTP front end How are things on the CS262 side? |
|
From: Jason I. H. <ja...@cs...> - 2002-11-11 18:40:27
|
Can anyone get Javadoc running with ant? I made a target called "javadoc" in each subproject, which worked at PARC but dies on my machine at Berkeley. -- Jason I. Hong | Group for User Interface Research ja...@cs... | University of California, Berkeley http://www.cs.berkeley.edu/~jasonh | http://guir.cs.berkeley.edu |
|
From: Jason I. H. <ja...@cs...> - 2002-11-11 07:29:43
|
Ok, the code is a little unsightly right now, but InfoSpaces now support XPath queries. I'm using the Jaxen XPath engine to do this. So now you can do local queries like: http://localhost:8080/infospace/jasonh?q=//ContextTuple[@type='location.room'] which means find all ContextTuple tags that have the type attribute equals to 'location.room' There's a nice XPath tutorial at: - http://www.w3schools.com/xpath/xpath_syntax.asp Some issues: - Be sure to use single quotes around String literals - I'm not sure if you can do wildcards, like @type='location.*' - I'm going to add some more URL parameters, like 'sort' and 'numdocs'. So a query might be something like: ...?q=//ContextTuple[@type='location.room']&sort=date-ascending&numdocs=10 - What should the query return internally? Right now it returns a List of Elements (org.w3c.dom.Element). They get transformed to XML Strings in the HTTP front end. What do you guys need for next week? Here's my current plan: - Cleaning up the code, adding more examples to the APIs - Creating regression test cases - Taking a whack at the .entity-*.xml files (like properties, security and privacy policies, etc) -- Jason I. Hong | Group for User Interface Research ja...@cs... | University of California, Berkeley http://www.cs.berkeley.edu/~jasonh | http://guir.cs.berkeley.edu |
